Checkpoint entries usually require a definitive Yes or No answer from the evaluating user. The result may be selected manually, or injected by a specific plug-in result.
However, a Checkpoint comes along with an expected answer, which is Yes by default. When the checklist is evaluated, the expected answer option is shown by marking it bold (as shown within the screenshot below). Even though this default setting may be switched to expect No as correct answer, the user is still forced to note a result. This default demand may be switched off by the don't evaluate option (see below).
If the expected answer is not the evaluation result, the executing user has to document a failure comment. The intention behind this Checkpoint behavior is to improve the test result quality by adding information about reasons for failures. If a checklist result is sent to the person that has to fix issues that came up during the evaluation process, getting details on circumstances and symptoms of an issue definitely support a quick and correct resolving
If a Checkpoint answer is not matching the expected answer, the result of the whole checklist is set to failed. This default behavior can be overridden by the Allow Exception option. If this option is enabled, users are requested to add a reason for the exception which will be displayed along with the standard failure comment.
This setting once again supports the idea of proper communication between the team members which are involved in the whole workflow of object creation and testing: Even though a checklist template editor may know which Checkpoints can trigger non-decisive exceptions, the evaluator himself may very well not be able to correctly judge which exceptional failure is acceptable and which one is not. At the same time it is possible that external dependencies, such as test environment settings or unusual test preconditions, take effect on the result, which should not lead to a general failure of the whole checklist.
Therefore, adding not only the option for exceptions, but at the same time a requirement for additional exception descriptions allows to document the check result in a proper manner for both - further test object and workflow improvements.
Use the links provided below to directly jump to detailed sections regarding available property setting options for checkpoint entry elements:
•Formatting the element description text with RayQC markup tags
•Adding a help file that may be opened within an external viewer
•Plug-ins can be added to use external script or executable logic for evaluation purposes.
•Conditions regarding the actual availability of the item itself (according to the general requirements for condition usage)
•Switching the value means to define No as expected result for this Checkpoint entry (not Yes as expected by default)
•If the Evaluate this element option is not checked, there is no expected check result, which allows to finish the evaluation independent from the actual answer
•Exceptions enable a successful checklist evaluation result even if this particular Checkpoint entry was marked to have failed
|
Tip: The result of Checkpoint entries can be selected as decisive condition for the availability of checklist groups and items. Please refer to the conditions section for details! |
Checklist Viewer display of a Checkpoint element with default setting: Yes is the expected, correct result. The background color may be grey or white due to the alternating schema of the group elements.
Checklist Viewer display of a Checkpoint element with switched value setting: No is the expected, correct result.
Checklist Viewer display of a Checkpoint element with don't evaluate setting: There is no explicit result expectation.
Checkpoint elements as they are displayed within the Checklist Editor interface. The background color may be white, light orange or orange due to the selection and hover state of the element.