Loading...
Testing provides evidence about selected behaviour; evaluation judges the outcome against its requirements. Keep expected results, observed results and subsequent changes distinct.
What you'll be able to do
Implementation translates models into data structures and algorithms into code. Clear modules, meaningful names and explicit interfaces make faults easier to isolate. Test the core behaviour before surrounding it with many dependent features, and preserve a reproducible input when investigating a failure.
A syntax error prevents valid interpretation; a runtime failure occurs during execution; a logical error can produce a wrong result without an exception. Debugging identifies and corrects causes, while testing supplies selected evidence that faults are present or that specified cases behave as expected.
Normal tests represent typical valid use. Boundary tests exercise limits and nearby cases; erroneous tests provide invalid types, formats or out-of-range values. For an inclusive integer range 1–10, test 1 and 10, nearby invalid 0 and 11, and a representative middle value.
Decide expected outputs before observing the program. A table should show the purpose, input, expected result, actual result and relevant evidence. Re-run affected cases after a repair so an apparent correction does not introduce a regression. Passing samples does not prove every possible execution correct.
Acceptance work with intended users checks whether the solution addresses their task and agreed needs. Evaluate each measurable objective using evidence, acknowledge unmet requirements and interpret independent feedback. Proposed improvements should be realistic and linked to observed limitations.
For Paper 1 preparation, practise reading, tracing, modifying and testing original programs, then use the centre’s authorised material for the relevant exam series. Record the changes and evidence requested by the task. There is no substitute for being able to explain your own code and verify a modification under the stated time and resource constraints.
| Input, valid range 1–10 | Category | Expected outcome |
|---|---|---|
| 5 | Normal | Accept |
| 1 and 10 | Valid boundaries | Accept |
| 0 and 11 | Just outside boundaries | Reject |
| "five" | Erroneous format | Reject or request valid input |
Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.
Common mistakes to avoid
Key takeaways
Test yourself
Answer a few questions, then review anything you missed.
Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.