There will be two main stages of testing for the new application during System Test :-
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.
Test Cases by Release version:
| Testing by Phase | |
| Acceptance 1 | |
| Release v0.1 | Functional 1 |
| User Acceptance | |
| Acceptance 2 | |
| Release v0.2 | Functional 2 |
| Regression 1 | |
| Acceptance 3 | |
| Functional 3 | |
| Release v0.3 | Performance 1 |
| Bash & Multi-User Testing | |
| Regression 1 | |
| Regression 2 | |
| Integration 1 | |
| Technical 1 | |
| Release v0.4 | Regression 1 |
| Regression 2 | |
| Regression 3 | |
| Installation Test | |
| Contingency | Per Bug Fix Test Only |
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).
| Functionality
to be Delivered * |
v0.1 1st May |
v0.2 17th May |
v0.3 31st May |
v0.4 18th June |
v1.0 29th June |
| 1. Function A | |||||
| 2. Process B | No New | Bug Fix | |||
| 3. Euro Reqs' | Functionality | contingency | |||
| 4. Y2K Reqs. | to be | release | |||
| 5. Inter Office Trans | delivered | only. | |||
| 6. International Trans. | in this | ||||
| 7. Other. | release. |
* (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.
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
