borderline data (or, if it does not, under which circumstances it fails).
Test plan clearly cross-referenced to evidence that the system has been tested during development and implementation.
Evidence of user testing.
• Software development
• Alpha testing
• Response to the results of testing
• Beta testing
• Response to the results of beta testing
• Modularisation of code
• Code documentation
• Use of modules, data structures and objects
• In-code documentation
• Code structure
• Applying the test plan and data
An attempt should be made to show that all parts of the system have been tested, including those sections dealing with unexpected or invalid data as well as extreme cases. Showing that many other cases of test data are likely to work – by including the outputs that they produce – is another important feature. Evidence of testing is essential.
The beta testing should cover all aspects of the test plan produced in the design section, which should cover all aspects of the design specification.
The examiner must be left in no doubt that the system actually works in the target environment.
This evidence may be in the form of hard copy output (possibly including screen dumps), photographs or any format that does not require access to any specific hardware or software. The end user(s) must be involved in this process and evidence of end-user testing is required.
11–14 marks
The testing covers as many different paths through the system as is feasible,
including valid, invalid and extreme cases. The testing covers all aspects of the
design specification and the test plan from the design section. There is clear
evidence of end-user testing.
8–10 marks
There is evidence of testing covering most aspects of the design specification but
with omissions, eg test data does not include erroneous data for all tests or there is
limited evidence of end-user testing.
No comments:
Post a Comment