Release Test Guidelines
The purpose of release tests is to test our software functionality on a macroscopic level.
Each iteration will have a task of defining the release test, and the last step in the iteration will be executing the release test.
Planning of release test (what to test)
- We should always have tests testing default behavior
- We should test that error scenarios are treated as expected
- New behavior in this iteration should be tested in some depth
- Behavior in previous iterations can be tested less thoroughly
- Bugs that need release testing will usually only be tested in the first iteration after the bug is fixed. Otherwise the test will be incorporated in another test
Principles of release test descriptions (how to test)
- The test should be operative and step-by-step. "Do this" "See that x looks like y". There should be no room for interpretation.
- The success criteria should be clear
- Running different parts of the release test should be possible independently and simultaneously
There is a template for writing release test steps
Execution of release test
- Each test should be run by persons who have not participated in the development of the code tested (at least in the first iteration where it is tested)
- Problems in the release test description can be fixed in cooperation with the release test coordinator
- Problems in the software must be reported to Bugzilla. the QA master must decide if this bug is critical for the success. If the bug is critical, it must be fixed, and the release test restarted.