A test table lists the inputs you will try and the output you expect for each, worked out before you run the code. A program works only when every row matches, not when one run looks right.
This lesson is part of advanced programming practice. It builds on the test-data idea in testing normal, boundary and invalid inputs.
How do I choose test data?
Sort your inputs into three groups. Each group catches a different kind of fault.
| Group | What it is | What it catches |
|---|---|---|
| Normal | Typical valid values | The main logic is wrong |
| Boundary | The edges of each rule and the values either side | Conditions with >, >=, < or <= in the wrong place |
| Invalid | Values the rules reject | Missing validation, crashes |
Start from the specification, not from the code. The specification says where the boundaries are.
Worked example: a grading program
An original task: a program reads a mark from 0 to 100 and prints a grade. The rules are that 80 or above is A, 60 to 79 is B, 40 to 59 is C, and below 40 is F. A mark outside 0 to 100 prints “Invalid”.
The boundaries are 0, 39, 40, 59, 60, 79, 80 and 100. The invalid values just outside are −1 and 101.
| Test | Mark | Type | Expected output |
|---|---|---|---|
| 1 | 75 | Normal | B |
| 2 | 92 | Normal | A |
| 3 | 80 | Boundary | A |
| 4 | 79 | Boundary | B |
| 5 | 40 | Boundary | C |
| 6 | 39 | Boundary | F |
| 7 | 0 | Boundary | F |
| 8 | 100 | Boundary | A |
| 9 | −1 | Invalid | Invalid |
| 10 | 101 | Invalid | Invalid |
The table has ten rows, and each has a reason to be there. Remove a boundary row and one kind of error goes untested.
The mistake: trusting one sample run
A common slip is to run the program once with a mark like 75 and call it finished. The output B looks right, so the program seems to work.
Suppose the program contains this condition.
IF mark > 80 THEN
PRINT "A"
ELSE IF mark >= 60 THEN
PRINT "B"| Test | Mark | Expected | Actual | Result |
|---|---|---|---|---|
| 1 | 75 | B | B | Pass |
| 2 | 92 | A | A | Pass |
| 3 | 80 | A | B | Fail |
Only test 3, the boundary, shows the fault. The code says > 80 where the rule says 80 or above, so it should be >= 80. A sample run at 75 would never have found it.
How to build a table in an exam
- Read the rules and underline every number.
- For each number, write that value and the values either side as boundary rows.
- Add one or two normal values in the middle of each range.
- Add invalid values beyond each end of the valid range.
- Work out the expected output for each row from the rules before looking at the code.
Check yourself
A youth ticket is sold to ages 13 to 17 inclusive. The program prints “Youth” for those ages and “Not youth” otherwise. Write a test table with at least six rows, including boundaries, and give the expected output of each.
Answer
Boundaries of the youth rule are 13 and 17, with the values just outside at 12 and 18.
| Age | Type | Expected output |
|---|---|---|
| 15 | Normal | Youth |
| 13 | Boundary | Youth |
| 17 | Boundary | Youth |
| 12 | Boundary | Not youth |
| 18 | Boundary | Not youth |
| 40 | Normal | Not youth |
| −5 | Invalid | Invalid age message, if the specification says to reject it |
If the specification does not mention invalid ages, say so in your answer and state what you assume. The four boundary rows are what expose a wrong > or >=.
What to study next
Try your tables on the advanced programming practice set. Log any boundary you missed in the mistake log and paper-error review.
If you want a teacher to build a test table with you for one of your own programs, see online one-to-one Computer Science tuition.