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 capturing test coverage in a test case and test run is not necessary, "exploratory" testing can also be used. This method is suitable for both experienced testers, and testers with less experience. The testers run through their requirements from the task on their dashboard, and by changing the status of the requirement immediately indicate whether the release note is Ok or Not Ok. If a requirement is Not Ok a defect must be manually created at the requirement. When defects is subsequently retested and Ok, the requirement must be manually set to Ok. Of course, testers can add comments to a requirement to capture the necessary information related to testing.
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.