Filling in Reports
In the standard test report form, the tester fills in the scenario text and, in the "Result" field, marks the execution status of each action. Comments and screenshots that explain problems encountered while executing the scenario can be inserted into the scenario text. Logs, dumps, and other binary files can be attached to the report using the "+ File" button.
Tracking effort and duration
In the Duration field you can enter the amount of time spent executing the test. You can also use the time-counting widget. When the test status is set, the automatically counted time is written to the "Duration" field. If you need to return to testing the test, choose "Return to work" in the "Actions" menu and start the timer again.
The actual duration of test execution helps estimate the overall testing effort for a set of scenarios or for an entire test plan. The effort of testing the documentation makes it possible to plan testing activities effectively.
The system compares the duration of the whole test report and of individual tests with previous runs and calculates the duration deviation, which is shown on the report form or in separate fields in the table of tests or reports. Duration deviation can be used to analyze problems with the application, for example if application performance has degraded.
Settings
The list of results and their color scheme can be configured in the corresponding reference list in the project settings. For each result (or test status) you can also specify:
| Parameter | Description |
|---|---|
| Prevent changing the test content in this status | In certain test statuses you can prevent its content from being changed, that is, prevent changes to the detailed description of the testing results. In this way, the state of the tests can be fixed at a particular stage of testing. |
| Project roles | Sometimes it is necessary to restrict the ability to make any changes to a test (content, overall result, duration, tester, and so on) in a particular status. In this field, list the project roles that will be allowed to make such changes. In this way, testers will not be able to correct the test after this result has been set, but a manager will be able to do so in order to correct mistaken actions, for example. |
Procedure
When a defect is found, it can be registered using the "+ Error" button. The defect description does not have to include every step that led to its discovery. A link to the test is associated with the defect. When a developer starts the fix, they can follow the link and restore, from the report, the context in which the defect was found. If the test scenario was linked to a requirement, the error is also linked to that requirement, informing project participants of problems in the implementation of the requirements.
Because test documentation is created from enhancements or primary requirements, one or more enhancements are linked to a test scenario item. Instead of creating a mass of defects whose cause is the incorrect implementation of a particular enhancement, create a task to fix the original defective enhancement. In different processes this can be organized in different ways:
| Process type | Actions for creating a fix task |
|---|---|
| Scrum, parallel work on requirements |
At the end of an iteration or sprint, the development team must deliver a quality product. To that end, a testing task is created during planning. If during testing it is found that a requirement was implemented incorrectly, a new fix task must be created (of the development type). After the requirement is fixed, the implementation must be checked again, and the testing task is marked complete only when the tests pass successfully. It is INCORRECT to reject a requirement. This may be done only at the demonstration. It is INCORRECT to reject a development task. The developer completed their task and spent the time. A new task to fix the errors may be done by another developer. Instead of controlling the number of rejections, control the value of the focus factor. |
| Kanban, sequential work on requirements | When an enhancement is tested, a link to it is shown on the right side of the report. If an error is found, perform the "Reject" action for that enhancement. The enhancement returns to the development queue, and the test report as a result of which the enhancement was rejected is linked to it. If there are no errors, the enhancement can be moved at once to the "Verified" state, and the time spent on testing can be logged. |
Updating documentation during testing
If a test needs to be updated (the scenario text in the test report), for example if the report has already been created but an error is found in the scenario text, use the "Update tests" action on that test scenario.
During manual testing, if an error is found in the scenario, you can first correct the test text and then update the scenario linked to it, using the "Update scenario" action.