Chapter 9 - Issues, Risks and Assumptions
1. No further changes or inclusions will be considered
for inclusion in this release except (1) where there is the
express permission and agreement of the Business Analyst and the
System Test Controller; (2) Where the changes/inclusions will not
require significant effort on behalf of the test team and will
not adversely affect the test schedule. This is a potentially
serious issue, as any major changes to design will entail
additional time to re-plan testing and to create or amend test
conditions
.
Resp : Byron Ruthlenn
Final list of inclusions to be Signed off.
2. The design of the software must be final, and design documentation must be complete, informative and signed off by all parties prior to System Test proper commences.
Resp : D.A. Stone
3. A weakness in the 'phased delivery' approach is that the the high degree of interdependency in the code means that the smallest changes can have serious effects to areas of the application which apparently have not been changed. The assumption of the test team is that previously delivered and tested functionality will only require regression testing to verify that it 'still' works. I.e. testing will not be intended to discover new errors. Because of this I recommend that there be a minimum 2 days regression testing AFTER the final fix/change has been retested. This however, imposes a fixed time constraint on the completion of system testing which requires the agreement of the Project Leader.
Resp : Byron Ruthlenn
4. Automated Testing
The majority of the Regression testing will be performed using
the automated test tool. However, due to the workload required to
implement (and debug) the test tool fully it is likely that the
return will only be maximised after the 3rd time running the
regression test suite for each release. The other major uses of
the test tool are for (1) Load Testing, (2) Multi-User Testing,
and (3) Repetitive data entry.
Resp : Test Controller