A test case is an input, the output you expect, and a reason that links them to a requirement. The reason is what turns a number into evidence. Questions may ask you to choose test data, name its type, or explain why a value was chosen.
This lesson is part of the problem-solving explanations module. It uses the ideas of normal, boundary and invalid data from validation, verification and testing, and links back to explaining the purpose of a variable.
How do you justify a test case?
Work in three steps.
- Read the requirement slowly. Underline the limits and the words that decide them: “from 0 to 20” includes both ends, “over 100” excludes 100.
- Choose values by type. Pick a normal value, the value on each limit, the value just outside each limit, and one wrong-type value if relevant.
- Write input, expected result and reason. The reason names the part of the requirement being checked.
A sentence frame helps: “This tests ___ because the requirement says ___, so the program should ___.”
Worked example
Requirement: a quiz score must be a whole number from 0 to 20 inclusive. Valid scores are accepted; anything else is rejected.
| Test data | Type | Expected | Reason |
|---|---|---|---|
| 10 | Normal | Accepted | A typical value inside the range. |
| 0 | Boundary | Accepted | “From 0” includes the lower limit, so 0 must pass. |
| 20 | Boundary | Accepted | “To 20 inclusive” includes the upper limit. |
| −1 | Boundary, invalid | Rejected | One below the lower limit, so it checks that the lower test is not too loose. |
| 21 | Boundary, invalid | Rejected | One above the upper limit, so it checks that the upper test is not too loose. |
| “abc” | Invalid type | Rejected | The requirement says a whole number, so text must not be accepted. |
Check the logic with a faulty rule. Suppose the code accepts when Score > 0 AND Score < 20. Then 0 and 20 are rejected, which contradicts the table. The boundary rows 0 and 20 expose the fault; the normal value 10 alone would pass and hide it.
The mistake to watch for
A weak plan looks like this:
Test data: 5, 10, 15. Reason: to check that it works.
All three values are normal, so they cannot reveal a wrong comparison. “To check that it works” does not mention the requirement.
The correction: keep one normal value, add 0, 20, −1 and 21, and give each a reason that quotes the rule, for example “20 tests that the upper limit is included”.
Check yourself
1. Requirement: a password must be 8 to 12 characters long. Give four test lengths and a reason for each.
Show answer
- 8 characters: boundary, accepted, because the rule includes the lower limit of 8.
- 7 characters: boundary, rejected, because it is just below the lower limit.
- 12 characters: boundary, accepted, because the rule includes the upper limit of 12.
- 13 characters: boundary, rejected, because it is just above the upper limit.
A normal length such as 10 could be added as a fifth test.
2. Requirement: a discount is given when the order total is over RM100. Why is a test of RM100 useful, and what is its expected result?
Show answer
“Over RM100” means strictly greater than 100, so RM100 itself gets no discount. Testing RM100 shows whether the program wrongly used >= instead of >. A second test of RM101 should receive the discount.
3. A test plan uses only 4, 9 and 14 for the rule “age from 12 to 18”. What is missing?
Show answer
There is no boundary data (12 and 18) and no value just outside the rule (11 and 19). Only 14 is inside the range, while 4 and 9 are far outside it, so the plan does not test the limits at all. Add 12, 18, 11 and 19 with reasons.
Where this leads next
Once a test fails, you need to explain how to fix the fault. That is the skill in describing a correction rather than merely showing code. The safe Python reasoning sandbox lets you run small tests against your own rule.
If your test values are sensible but your reasons stay vague, our teachers can work through them with you in online one-to-one Computer Science tuition.