In standard form of the test report, a tester fills out the scenario text and sets the execution state for each of actions in "Result" field. You can insert comments and screenshots into the scenario text to clarify problems encountered during the scenario execution.
Logs, dumps, and other binary files can be attached to the report using "+ File" button.
If an error is detected, you can register it using "+ Error" button. You need not to describe all actions that led to its detection. The error will be linked to the test report position. When a developer begins fixing, he can follow this link and restore the context of error identification. If a test scenario was bound to the requirement, the error will also be bound to this requirement. Thus, project members will be informed about the problems with requirement implementation.
Since test documentation is created based on enhancements or source requirements, the test scenario position will be bound to one or more enhancements. You should set a task for fixing the source erroneous enhancement rather then create a lot of errors caused by the incorrect implementation of a particular enhancement. You can organize it using different ways for different processes:
| Type of process | Actions to set a task for fixing |
|---|---|
| Scrum, concurrent working on requirements |
When iteration or release is finished, a development team must deliver a quality product. To do this, you should create a test task during the planning. If during the test process you detect that a requirement is implemented incorrectly, you must create a new task for fixing it (having “development” type). When the requirement is fixed, you should check the implementation again and mark a test task as completed only after the successful passing of tests. It’s INCORRECT to reject a requirement. This can be done only during the demonstration. It’s INCORRECT to reject a development task. A developer completed his task and spent his time. A new task for error fixing will possibly be done by another developer. You should control value of focus factor rather then number of deviations. |
| Kanban, sequential working on requirements | When an enhancement is tested, its link is displayed in the right part of the report. If an error is detected, you should execute "Reject" action for this enhancement. The enhancement will be returned to the development queue, and it will be linked to the test report which caused the rejection of this enhancement. If there are no errors, you can transit the enhancement to "Verified" state and log time spent for testing. |
List view of the report is a convenient way to execute bulk operations and view all results by the specified criteria. For example, to accelerate working on a big test plan, you can distribute the work between several testers. Select part of test scenarios and assign them to a particular tester. When filling out a report, tester can filter out and fill only his positions.