Testing and debugging properly
Computer Science · GCSE · The School
Three kinds of test data
NORMAL data is what you expect (age 25). BOUNDARY data sits at the edges (0, 1, 17, 18 for an adult check) — this is where most bugs live. ERRONEOUS data is what should be rejected ("banana" as an age). A test plan without boundary data misses the very cases that break real programs.
Three kinds of error
SYNTAX errors break the rules of the language and stop it running — the easiest kind, because the computer tells you. RUNTIME errors crash it mid-way (dividing by zero). LOGIC errors are the dangerous ones: the program runs happily and produces the WRONG answer, and only testing finds them.
Debug by halving
Do not guess. Find an input that fails, then narrow: print values halfway through and see whether they are already wrong — that halves the suspect region each time. Change ONE thing, re-test, and keep a note of what you tried. Systematic beats clever, especially at 2am.
The box should accept an age between 0 and 120. NORMAL: 25 — accepted. BOUNDARY: 0 accepted, 120 accepted, −1 rejected, 121 rejected. Those four are where the off-by-one errors live. ERRONEOUS: "twenty", an empty box, 25.5, a 3,000-character string — all rejected without crashing. Testing only 25 tells you almost nothing; the boundaries and the rubbish are where programs actually break.
Iterative testing is not the same as final testing
Iterative testing happens while you build, on the piece you just wrote, and its purpose is to find faults early. Final testing happens on the finished program against the original requirements, and its purpose is to show it does what was asked. Projects lose marks for reporting only the second.
A test plan is a table, written before the code
Test number, what is being tested, the data used, the type of data, expected result, actual result, action taken. Writing it first forces you to decide what correct means; writing it afterwards tends to produce tests the code already passes, which proves nothing.