4.14.2.1–4.14.2.2, 4.14.3.5–4.14.3.6, 4.14.5.4–4.14.5.5, 4.14.6 - Project testing, evaluation and evidence quality

Representative tests and robustness

Testing should demonstrate the core requirements and the robustness of the complete or nearly complete solution, or the thoroughness of an investigation, through carefully selected representative cases.

Start from the objectives and the behaviours or assumptions at risk. A fictional equipment store accepts a quantity only when it is a whole number from 1 to 20. A normal value such as 8 checks ordinary success. The boundaries 1 and 20 check inclusive limits. Values just outside, 0 and 21, check rejection; a non-numeric entry checks type handling where such entry is possible. Choose the expected result before looking at actual output, so that the output is not treated as correct simply because the program produced it.

Include interactions and important failure cases, not just isolated successful functions. Returning an item should change availability; a subsequent loan should see that change. If persistent data is required, a restart test can reveal whether the change was actually saved. If a service may fail, test the agreed failure response. These choices depend on the requirements; there is no fixed number of cases that proves every system correct.

For an investigation, test the measurement method and assumptions. Use cases with a known outcome to check a computation, vary relevant conditions and include meaningful limits. A repeatable run with controlled conditions is stronger evidence than an unexplained chart. Testing can take place during coding or after the whole solution is coded. Keep enough detail to connect a result to the version and conditions tested.

Representative evidence does not mean testing only convenient cases. Carry out sufficiently thorough tests, then select a balanced sample showing core functionality, important limits and robustness. No finite set proves that a program has no possible defects.

Clear records of expected and actual results

A reader must be able to tell what was tested, why it matters and what actually happened.

Introduce the tested functionality and provide a structured record, often a table. Include the test performed, its purpose where not obvious, test data, expected outcome, actual outcome and a carefully selected sample of evidence. Link the test to its objective and relevant version. Screenshots before and after a state change, a trace or an output extract can support the record; a screenshot without explanation can leave both the starting state and result ambiguous.

The table is an invented teaching example, not evidence from an executed student program. In your own work, record real results. Do not fill the actual-result column with a prediction or claim an unperformed test passed.

If a test fails, retain the original evidence, explain the correction and retest the affected behaviour. Check nearby requirements for regressions. A later passing result does not make the earlier failed run disappear; distinguish versions and outcomes. Present representative samples rather than every possible screenshot, but ensure the selection does not hide a core failure.

Evaluation against every requirement

Evaluation turns the evidence into a reasoned account of how well the outcome meets all of its requirements.

Use the numbered objectives to organise the judgement. For each, identify evidence, state whether it is met, partly met, not met or not demonstrated, and explain the effect on the overall solution. Do not ignore requirements that were unsuccessful. Distinguish a real defect from an agreed out-of-scope extension, and distinguish an untested claim from an observed failure.

For an investigation, consider whether its planned question was answered, whether the method and datasets justify the conclusions, and which limitations restrict their generality. A correct graph does not establish a conclusion about conditions never investigated. Explain uncertainty rather than hiding it behind a confident final sentence.

The formal testing grid ranges from Level 1 (1–2), where a small number of tests shows some functionality or investigative outcomes and the evidence may be unclear, through Level 2 (3–4), with explained moderately extensive testing but insufficient proof of robust achievement, and Level 3 (5–6), with extensive testing but unclear or missing proof of core requirements, to Level 4 (7–8), with clear representative evidence of thorough testing, robustness of the complete or nearly complete solution/thoroughness of investigation and achieved requirements. The distinctions concern the quality and coverage of evidence, not a count of screenshots.

The formal evaluation grid distinguishes:

These official descriptors guide understanding; an automated practice score cannot certify a formal NEA award.

Independent feedback and realistic improvements

Feedback adds another perspective, but it becomes useful evidence only when it is relevant, realistic and discussed critically.

Ask intended users or recipients to undertake meaningful tasks or examine suitable findings. “Looks nice” gives little evidence about whether the objectives were met. “I could not tell which item had been selected before confirming the loan” identifies an actionable usability problem. Discuss how representative the observation is, compare it with other evidence and explain why a suggested change is accepted, modified or rejected.

Feedback collected during prototyping can contribute to the final account. Reference where it can be found and explain how and why it affected the solution. Do not invent independent comments or simply reproduce them without analysis.

Propose realistic improvements if the problem were revisited. Connect each improvement to an observed limitation, explain how it would help, consider feasibility and specify how success would be tested. For example, add a clear confirmation showing the selected item before committing the loan, then ask representative users to complete the task and check errors. If feedback requests payment processing outside the agreed scope, explain whether that is a worthwhile future extension and what additional work it requires.

An improvement is not automatically the feature requested by the loudest user. Judge it against objectives, evidence and constraints. Address defects in core requirements before speculative additions.

Best-fit levels and the mark within a level

The formal level-of-response process judges the overall quality of a section before selecting its mark.

The teacher first reads and annotates the work for the qualities in the relevant descriptor. Starting with the lowest level, they consider whether the section meets it, then move upwards until the descriptor best fits. A descriptor represents typical performance; it is not a requirement that every small detail match perfectly. If evidence combines levels, use overall quality: mainly Level 3 with a small amount of Level 4 remains Level 3, with that stronger evidence helping place the mark near its top.

After choosing the level, choose the mark within its range, using AQA-standardised exemplars and the quality and consistency of the evidence. Re-read relevant work when necessary to check that the judgement is appropriate. A section containing nothing relevant to that assessed area receives zero; it does not automatically get the bottom positive mark just for existing.

Do not turn best fit into a mechanical checklist or average the level numbers from isolated pages. One excellent screenshot cannot outweigh missing evidence of most core requirements. Conversely, one minor weakness need not force an otherwise strong section down a level. Teacher judgement and standardisation are essential. The original short practice rubrics here award stated skill points and do not apply this formal process to a learner's project.

The official totals and assessment objectives

The formal NEA totals show where evidence contributes to assessed application, design, development and evaluation skills.

The arithmetic is 9 + 12 + 42 + 8 + 4 = 75, while the AO3 areas total 12 + 42 + 8 + 4 = 66. The official AO labels identify the assessed kinds of achievement; they are not extra marks or separate subscores to add to the section marks. Evidence should remain findable in the five-section framework even though development was iterative.

Use these totals to understand the emphasis on independent practical achievement and relevant evidence. A six-mark formative testing exercise has its own six-point rubric; it is neither six of the formal eight testing marks nor an AO3c judgement about a complete assessed project.