Executing a Test Run
Last updated
Last updated
Once the Test Run is set up, it is recommended to set the Test Run status to Executing. This indicates to all Testers that they can start executing their Tests. The Test Run can be accessed by multiple users in parallel.
To execute a Test, click on the arrow/play button on the Test row and an Execution object will be displayed. Data from the Test Case, Configuration, and Test Run is automatically copied to the Execution copy according to the definition in the templates. Fill out the necessary fields in the Test Result object. If applicable, creates and assign Issues/Deviations to test steps that are not passed.
In the Test Result, the Execution Number attribute in the Test result will be equal to “1” (first execution of the Test Case).
Save the Test Result object. The Test Run will now indicate the result of the execution in the Test Grid and in the progress bar on the Test Run main page.
You can continue working on a Test Result by opening it and modifying/completing it. Any changes will be stored as a new revision of the Test Result, but the Execution Number will remain, indicating that all changes belong to the same Execution.
It is likely that the same Test Case will be executed several times for new versions of the device. Subsequent executions will be recorded in the same Test Result object, with an increment of the Execution Number.
As long as a Test Case has not been executed, the user is free to update the Test Case. The Test Run will automatically update itself to reflect your changes. The same goes for the Configurations.
However, as soon as a Test has been executed, updating the Test might invalidate the result. Therefore, when opening a Test that has been executed and is part of a non-completed Test Run, you will be duly warned that editing the Test might invalidate the current Test Result.
If you go on and update the Test, Aligned Elements will:
Mark the Test row as invalid in the Test Run, painting the corresponding row grey.
Prevent you from making any changes to the objects in the Test Row.
The Test Run is now in an inconsistent state. To resolve the situation, you must use the Refresh button. This will present you with two choices:
1) Update the Test to the most current revision and invalidate the Test Result. The Test Result is removed from the Test Run. This situation is applicable if the change to the Test was major and makes the existing result invalid.
Note! Even though the Test Result is removed from the Test Run, the trace between Test Case and the Test Result remains.
2) Update the Test to the most current revision and declare the existing Test Result to be consistent with the update of the Test. This implies automatic copying of the attribute values in the Test Case to the Executed Test Case where applicable. This situation is applicable if the update to the Test was minor and does not affect the result. In this case, the data from the Test Case is written into Executed Test Case.
Note! This second option is not applicable if the same Test Case has been executed in a different Test Run with the same configuration.
Note! The second option cannot be applied if the Test Case has changed the number of rows as part of its change.
A similar behaviour is triggered if you modify a Configuration that has been used in a Test Result.
Click Remove and confirm to remove the Test case from the Test Run.
Note! Removing a Test case (and its Test Result) from a Test Run does not mean that the Test or Test Results are disabled or that the Test Run information is removed from the Test Result.
Note! If a Test Case was executed to create a Test Result, then remove from the Test Run and then added back, the Test Result (and, if applicable, the Configuration) will also be added back to the Test Run.
