Test Data

Cambridge expects you to use FOUR types of test data — each one exposes a different kind of bug.

Normal data. Valid data the algorithm should ACCEPT and process correctly. Confirms the everyday case works. Example for an exam-mark algorithm (0-100): 67.

Boundary data. Values right at the EDGE of the valid range — both just inside and just outside. Catches off-by-one bugs.

• Just INSIDE: 0 (lowest valid), 100 (highest valid).
• Just OUTSIDE: -1 (just below valid), 101 (just above valid).

Abnormal / erroneous data. Data that should be REJECTED — wrong type, completely out of range, wrong format. Confirms validation works. Example: 'A' (not a number), -5, 200.

Extreme data. Largest and smallest VALID inputs — used to stress-test. For our 0-100 mark example, the extremes coincide with the boundary inside-values (0 and 100). For a 'first-name' field, extremes would be 'A' (a single letter, valid) and a very long valid name.

Cambridge tip. Mark schemes consistently expect ALL FOUR types named with examples. Listing only normal data is a 1-out-of-8 answer.

Syntax error. Code BREAKS the rules of the language — missing bracket, mistyped keyword, missing semicolon, wrong indentation in Python.

• When caught: by the translator (compiler / interpreter) BEFORE execution.
• How to fix: read the error message; the translator usually points at the line.
• Example: IF X = 5 THN OUTPUT 'big' — THEN is misspelled.

Logic error. Code RUNS without complaint but produces the WRONG result.

• When caught: during testing — comparing actual output against expected output.
• How to fix: trace tables, breakpoints, careful reading.
• Example: IF Mark > 40 THEN Pass ← TRUE ENDIF when the rule is 'pass at 40 or above' (should be >=).

Run-time error. Code passed compilation but CRASHES during execution.

• When caught: the program stops with an error message at the moment the bad operation happens.
• How to fix: add input validation, defensive checks, or try/catch.
• Example causes: division by zero, array index out of bounds, file not found, network unreachable, stack overflow.

Cambridge tip. When asked to identify the type of error, ask 'WHEN was it caught?' — translator (syntax), test results (logic), program crash (run-time). The timing tells you the type.