In this page and subpages we detail the procedures for release testing

Description

The overall preparation is continuously defined and implemented
Setting the exact successcriteria together with the developers for each implementation task
Preparing the release test description, data and platform for the releasetest

Purpose

A reliable releasetest for all changes made in the actual iteration
A releasetest ready for execution just after the last iteration task is finished

During the iteration the following task need to be performed by a proactive Testcoordinator (MSS):

The creation of the Wiki test release page happens soon after the start of the iteration. The simplest way of doing this is to copy the previous Release test reports.
The Test Coordinator will work together with the developer to decide who is responsible for implementing the releasetest.
Before the implementation of a task the deleloper defines how the release test can be implemented. Unit tests may be sufficient testing so that a proper release test is not necessary.
Accepted by the test coordinator.
The tests covers the need for each iteration. By development iterations - not production releases - the test focus is only on the code areas, that may be affected by the changes.
That documentation will be verified.
That each release test is checked as far as possible before the start of the release test
That there is clean up of the release test page for old test cases and bug test items.
That the time for preparation and execution of the release test is fair.
That the platform has sufficient capacity (disk space platforms ..)
That each test ready for execution is spread out to different testpeople

After the iteration has been started and tasks distributed by [[Process Role/Project Leader|project leader]]
Before [[Process/Code Freeze|code freeze]] within the iteration

Component owners are responsible for testdata and sanity checks and for providing the test coordinator with a list of bugs fixes and a sanity check descriptions