> [[provide|Provided]] [[annotate|annotated]] evidence of post development testing for function and robustness[^1]. Testing to inform evaluation is worth only 5 marks, but it forms the foundation of your final evaluation. Final product testing is one of the two key components of this stage, and without strong evidence here, it may be difficult to access all marks in the final evaluation. The purpose of your testing in this section is to look at your solution holistically, generating evidence about whether it meets the goals of your original design and the requirements of your stakeholders[^2]. > [!check] Moderators' report > Students who do well generally have separate final product testing from their testing during development as testing evidence can only be credited once[^3]. Successful students generally include "distinct robustness testing" to stress test their solutions "to destruction"[^4]. As the purpose of the testing in this section is to evaluate the entire final product, it "should include whole system black box tests"[^2]. While testing in during development may be more [white-box](https://www.geeksforgeeks.org/software-testing/software-engineering-white-box-testing/), testing in the evaluation is typically more [black-box](https://www.geeksforgeeks.org/software-testing/software-engineering-black-box-testing/). This testing will likely lean on earlier work but could include new tests[^2]. There is no need for you to repeat tests you have done before; instead, you can just refer back to them with page numbers, links, or (if you numbered your tests) test numbers—as long as it is clear where the work was originally done[^2]. This also is an opportunity for you to complete any unused tests from your design. You will ultimately need to demonstrate [[Use of test evidence in relation to success criteria|use of test evidence in relation to success criteria]] so best practice would involve considering whether your tests cover your [[Success criteria|success criteria]] comprehensively. Tables are efficient ways to present test evidence. Video evidence can help to show the "dynamics of a system" which can be particularly beneficial if your product is a game[^2]. The higher mark bands require testing both for function and robustness. > [!warning] Moderators' report > "Often … there are too few tests to realistically say the system has undergone rigorous robustness testing[^3]. ## Notes [^1]: OCR, “Computer Science H446 A Level Specification,” OCR, March 2024, 25, https://www.ocr.org.uk/Images/170844-specification-accredited-a-level-gce-computer-science-h446.pdf. [^2]: Cambridge OCR, A Level Computer Science: A Guide to Creating Concise NEA Documentation, 2026, video, 39:05, https://train.ocr.org.uk/mod/scorm/view.php?id=1893. [^3]: OCR, “A Level Computer Science Moderators’ Report H446/03/04 Summer 2023 Series,” OCR, 2023, 7, https://www.ocr.org.uk/Images/703603-moderators-report.pdf. [^4]: OCR, “A Level Computer Science Moderators’ Report H446/03/04 Summer 2024 Series,” OCR, 2024, 5, https://www.ocr.org.uk/Images/726389-moderators-report.pdf.