After customizing and importing release notes, the testing process based on the release notes can begin. This process consists of the following steps:
1. Reviewing release notes and assigning testers
From his task on the dashboard, the reviewer can go through the requirements to be reviewed. He indicates whether something should be tested. If the reviewer thinks someone else should review a requirement he can modify the reviewer. With that modification, the new assessor automatically receives an email.
The reviewer gives the requirement the status "Ready for Test" when it can be tested. A tester can also be assigned to the requirement. This person receives an e-mail of this.
Optionally, all requirements can be reviewed first, and only then can testers be assigned. This can be done by filtering for "Ready for Test" status in the requirements list after reviewing. You can then populate the tester for all these release notes via mass change. At that point, the testers will receive an email. Of course, the tester can also be a group. In that case, make sure that all members of the group receive an e-mail. This can be adjusted within the group's settings.
2. Release Notes Testing
Once the requirements have been reviewed, the testers can begin testing. This can be done in two ways: scenario-based or exploratory. Depending on the desired level of test coverage, and the test experience of the testers, choose the desired method:
Scenario-based
A test case is created for each requirement, which can be executed in a test run. This traditional flow is somewhat more suitable for testers with reasonable test maturity.
Exploratory
When it is not necessary to record test coverage in a test case and test run, exploratory testing can also be used. This method is suitable for both experienced testers and testers with less experience:
- The testers go through their requirements from the task on their dashboard and immediately indicate whether the release note is OK or Not OK by changing the status of the requirement. The planned and executed tests can be recorded in text fields such as "Test ideas" and "Executed test." You can create these fields yourself in the customizing.
- If a requirement is given the status 'Test not OK', the user is prompted defect a defect for the requirement*.
- When defects retested and are OK, the requirement must be manually set to OK.
*In the customization for the "Status" requirement field, you can set which statuses defect a defect to be created.
3. Release notes approve
If a requirement is Ok tested you can choose to have the reviewer still approve it. From the task on his dashboard the reviewer can go through the requirements that are OK and give them, for example, the status 'Ready for production' (or 'Approve reviewer'). This approves the release note and completes the process.