A test plan is a table that lists every test you intend to run on a program, the input you will use, the expected output, and the actual result after running the test. It provides systematic evidence that a program works correctly across normal, boundary, and erroneous inputs.
Why do programmers create test plans rather than just running the program?
Clicking "run" and checking the output informally is not testing — it is hoping. A test plan forces you to think about what your program should do before you run it. This separates the question "is the expected result correct?" (design thinking) from "does the code produce the expected result?" (testing). Without that separation, bugs hide because the programmer unconsciously adjusts their expectation to match the broken output.
Test plans also create a written record that the program has been tested, which is required for your GCSE project portfolio. Examiners expect to see evidence of systematic testing, not just a screenshot of one successful run.
What are the three categories of test data?
Every complete test plan covers all three categories:
| Category | Definition | Example (age input, valid range 0–120) |
|---|---|---|
| Normal | Valid data within the expected range | 25 |
| Boundary | Values at the exact edges of the valid range | 0, 120 |
| Erroneous | Invalid data — wrong type, out of range, or blank | "hello", -1, 200, "" |
Boundary values are particularly important because programs often fail at the edges: a condition written as age > 0 will incorrectly reject 0 if it should be valid. Boundary testing catches off-by-one errors that normal data misses.
What columns should a test plan table include?
A well-formed GCSE test plan table typically has six columns:
| Test number | Description | Test data | Expected output | Actual output | Pass/Fail |
|---|---|---|---|---|---|
| 1 | Normal age input | 25 |
"Valid age" displayed | "Valid age" displayed | Pass |
| 2 | Lower boundary | 0 |
"Valid age" displayed | "Valid age" displayed | Pass |
| 3 | Upper boundary | 120 |
"Valid age" displayed | "Valid age" displayed | Pass |
| 4 | Just below lower boundary | -1 |
Error message displayed | Error message displayed | Pass |
| 5 | Just above upper boundary | 121 |
Error message displayed | Error message displayed | Pass |
| 6 | Wrong data type | "abc" |
Error message displayed | Program crashes | Fail |
| 7 | Empty input | "" |
Error message displayed | Program crashes | Fail |
Tests 6 and 7 reveal bugs — the "Actual output" column shows the real result after running, and a mismatch means you have found a defect that needs fixing.
How do you decide which tests to include?
A practical strategy for GCSE projects:
- List every input your program accepts (from the user or from a file).
- For each input, identify the valid range or type.
- Write at least one normal, one boundary, and one erroneous test per input.
- Add tests for any selection (IF/ELIF branches) — ensure every branch is exercised at least once.
- Add tests for edge cases in algorithms (e.g. sorting an already-sorted list, searching for an item not in the list).
The goal is path coverage: every branch of your code must be tested at least once. Missing a branch means a bug could hide there undetected.
What is the difference between the expected output and the actual output columns?
This distinction is the heart of testing:
- Expected output — what should happen according to your design. You fill this in before running the test. It comes from your requirements or specification.
- Actual output — what does happen when you run the program with the test data. You fill this in after running the test.
A match = Pass. A mismatch = Fail = a bug to fix. If the actual output surprises you in a good way (the program does something better than expected), your expected output was wrong — go back and fix the requirement, not just the test record.
How does a test plan link to iterative testing?
GCSE Computer Science distinguishes between iterative testing (testing during development, fixing bugs as you find them, then retesting) and final testing (a complete pass through the test plan when the program is finished).
Your test plan should be used for both: run each test as you complete each feature, mark the result, and return to any failing tests after fixing. The final submission should show all tests passing (or, if some genuinely cannot be fixed, an honest explanation of the known limitation).
Frequently asked questions
Does the test plan need to go in my project portfolio?
Yes — for most awarding bodies, evidence of testing is a distinct assessment criterion. AQA expects a test plan with test data, expected results, and actual results, plus evidence that failing tests were addressed. OCR has a similar requirement. Without it, you cannot achieve the top mark bands for the testing criterion.
How many tests are enough?
There is no fixed number, but as a rule of thumb: a minimum of three tests per distinct input (normal, boundary, erroneous), plus at least one test per IF/ELIF branch. For a typical GCSE project with three or four inputs and five or six branches, you might expect 15–25 tests. Quality matters more than quantity — ten well-chosen tests beat fifty trivial ones.
Should I include tests that I know will fail?
Yes, in your iterative testing records. Showing a failing test, fixing the bug, and then showing a passing retest is exactly the kind of evidence examiners want to see — it demonstrates that you understand testing as a process, not just a pass/fail checkbox.
Can I write a test plan before I have written any code?
Yes, and doing so is considered best practice. Writing your tests first (sometimes called test-driven development) forces you to define exactly what your program should do before you write it. At GCSE, creating the test plan from the requirements document, before any coding begins, shows sophisticated planning that can earn top marks for the design section.
Get personalised help building and improving your GCSE test plan with Professor Turing at aitutors.me.