The main thrust of the approach is to intensively test the front end in the first two releases, thus raising approximately 80% of errors in this period. With the majority of these errors fixed, standard and/or frequently used actions will be tested to prove individual elements and total system processing in Release v0.3. Regression testing of outstanding errors will be performed on an ongoing basis.

When all errors (which potentially impact overall processing) are fixed, an additional set of test cases are processed in Release v0.4 to ensure the system works in an integrated manner. It is intended that Release v0.4 be the final proving of the system as a single application. There should be no A or B class errors outstanding prior to the start of Release v0.4 testing.

3.1.1. Test Cases by Release version:

3.1.2. Automated Testing

Automated testing tools will be used in the test environment for functional and regression testing. The main focus of the automated testing will be the regression testing of the previously delivered functionality - i.e. when development version 0.2 of the software is delivered the majority of the regression testing of the functionality delivered in development version 0.1 will be automated. It is estimated that the full benefit of the automated testing will only occur when the tests have been executed three or more times.

During System Test the release of new versions of the software will be co-ordinated between the Development Team leader and the System Test Controller. However, unless it concerns a fix to a very serious error, new versions should only be released when a agreed targets have been reached (i.e. the next version contains fixes to X or more numbers of bugs).

Release Schedule:

* (per functional spec, by priority)

Notes:
It is intended that 80% of the functionality will have been tested in full prior to the Phase 3 Release.
All the functionality must be present in the Phase 3 Release.
No previously undelivered functionality will be accepted for testing after Phase 3.

3.3. Formal Reviewing

3.3.1. Formal Review Points

1. Design Documentation - Requirements Specification & Functional Specification

2. System Test Plan

3. Unit Test Plans & Test Conditions

4. Unit Test Results

5. System Test Conditions

6. System Test Progress/Results

7. Post System Test Review

8. Integration Test Results

9. Pilot Implementation Review

10. Project Review

The diagram above outlines the Test Approach. Boxes 1 - 6 show the major review stages prior to Test execution. Boxes 7 - 10 show the phases planned for & after test execution.

While the above diagram concentrates on the testing aspect of SQA's role, there is an ongoing role also, in ensuring the quality of the major deliverables throughout the lifecycle of the project. SQA's role will be to ensure that all Quality Inspections occur for all the agreed deliverables and that follow up actions and initiatives are pursued.

3.3.2.  Progress/Results Monitoring

• Acceptance Test 1 Results
• Test Results - Release v0.1
• Test Results - Release v0.2
• Test Results - Release v0.3
• Performance Test 1 Results
• Regression 1 & 2 Results
• Test Results - Release v0.4
• Technical Test Results