A program fails at a boundary when its condition treats the edge value differently from what the problem says. The usual cause is < where <= is needed, or > where >= is needed. The fix is to choose boundary test data before you write the condition.
Below is one worked example with a trace table, then a second short one. Notation is simple pseudocode. Your route may use a specific style, so confirm it on the Cambridge page.
What does a boundary bug look like?
A school system should accept a test mark from 0 to 100 inclusive. Here is the first attempt.
INPUT Mark
IF Mark > 0 AND Mark < 100 THEN
OUTPUT "Accepted"
ELSE
OUTPUT "Rejected"
ENDIFTry a few values. A student tests 50 and 75, sees “Accepted” for both and moves on. Now trace a fuller set.
| Mark | Mark > 0 | Mark < 100 | Output | Expected |
|---|---|---|---|---|
| 50 | TRUE | TRUE | Accepted | Accepted |
| 0 | FALSE | TRUE | Rejected | Accepted |
| 1 | TRUE | TRUE | Accepted | Accepted |
| 99 | TRUE | TRUE | Accepted | Accepted |
| 100 | TRUE | FALSE | Rejected | Accepted |
| −1 | FALSE | TRUE | Rejected | Rejected |
| 101 | TRUE | FALSE | Rejected | Rejected |
Two rows fail: 0 and 100. Both are real marks that the program wrongly rejects. The ordinary tests never reached them.
How do I fix it?
Include the limits in the condition.
IF Mark >= 0 AND Mark <= 100 THENRe-trace the failing rows. Mark = 0 gives TRUE and TRUE, so Accepted.
Mark = 100 gives TRUE and TRUE, so Accepted. Mark = −1 gives FALSE, Rejected.
Mark = 101 gives FALSE on the second test, Rejected. All seven rows now match.
How do I choose boundary test data?
For a range with lower limit L and upper limit U, both inclusive:
| Purpose | Values (L = 0, U = 100) |
|---|---|
| On the lower limit | 0 |
| Just inside the lower limit | 1 |
| Just outside the lower limit | −1 |
| On the upper limit | 100 |
| Just inside the upper limit | 99 |
| Just outside the upper limit | 101 |
Write the expected result before you run anything. If you choose the expected result after seeing the output, the program is marking its own homework.
A second example: “more than” and “at least”
A shop gives free delivery when the order total is at least RM50. The code is:
IF Total > 50 THEN
Delivery ← 0
ELSE
Delivery ← 5
ENDIF| Total | Code gives | Correct |
|---|---|---|
| 49.90 | 5 | 5 |
| 50.00 | 5 | 0 |
| 50.10 | 0 | 0 |
Only the boundary value 50.00 exposes the fault. The words “at least” mean 50 is included, so the condition should be Total >= 50.
Words that signal an inclusive or exclusive edge
| Wording | Condition |
|---|---|
| at least 50, 50 or more, from 50 | Total >= 50 |
| more than 50, over 50 | Total > 50 |
| at most 50, up to and including 50 | Total <= 50 |
| fewer than 50, under 50 | Total < 50 |
Underline the wording in the question and choose the symbol from this table, not from habit.
A checklist before you submit a condition
- Circle the limits in the question and decide if each one is inclusive.
- Write your boundary values and the expected result of each.
- Trace the two or three edge values through the condition by hand.
- Include one value outside each limit, and one abnormal input.
- Re-read: does the symbol match the wording?
Use the restricted pseudocode trace trainer to step through an original algorithm, and the safe Python reasoning sandbox to see a failing test with an explanation prompt, where your route allows it.
Where to go next
The full topic is in validation, verification and testing. If loops are also giving you trouble, read my loop runs forever or misses the last item. The original practice set has a test-data question, and the learning guide shows where it fits.
When self-checking is not enough
If you trace the edge values and still write the wrong symbol under time pressure, the gap is often in how you read the wording. A teacher can give you short, varied questions and listen to how you decide. Online one-to-one Computer Science tuition starts with a paid one-hour trial at the assigned teacher’s confirmed rate, from RM80.