Find your next learning step
Read the quick answer, work through an example, or go straight to practice.
Full article contents
- The quick answer: the requirement is the reference point
- Worked example: the club entry rule
- Choose checks that can expose the mistake
- Trace the conditions instead of guessing
- Why AND and OR cannot be swapped casually
- Debug one cause and then check the repair
- Practice with worked answers
- For parents and tutors: inspect the thinking behind the screen
Did you know? A program can start, finish and display an answer while still getting the task wrong. G2 Computing students need to distinguish a successful run from a correct solution.
This G2 Computing guide explains logic errors through a small decision rule. You will learn to predict an answer, trace the program and choose inputs that expose a mistake near the point where a decision changes.
SEAB lists G2 Computing as K237 for the 2027 SEC examination. Its learning includes analysing and debugging programs. The rule, pseudocode and checks below are original teaching examples; the boundary-checking method is a practical learning technique, not a claim about a separately named examination requirement.
SECTION 1 OF 8
The quick answer: the requirement is the reference point
A program is correct for a task when its behaviour matches the stated requirements for the relevant inputs. Running without an error message does not establish that match.
An error in the grammar of the programming language may prevent a program from starting. A problem encountered during execution may interrupt a run. A logic error can allow the program to complete while producing the wrong result.
Start with the required behaviour in ordinary language. Then write expected results before comparing them with what the program actually does.
This order matters. If you decide what the program ought to do by reading the faulty code, you can accidentally treat the mistake as the rule.
A test is useful when it can distinguish correct behaviour from a plausible error. Ten nearly identical examples may tell you less than a few carefully chosen ones.
SECTION 2 OF 8
Worked example: the club entry rule
Original practice rule: a school activity accepts students whose age is at least 12 and at most 16. Assume that the input has already been checked to be a whole-number age.
A student writes this language-neutral pseudocode: IF age > 12 AND age < 16 THEN display ‘Eligible’; ELSE display ‘Not eligible’.
The program accepts ages 13, 14 and 15. Those results look sensible. But it rejects 12 and 16, even though the written rule includes both ages.
The mistake is in the comparison operators. ‘At least 12’ includes 12, so the lower comparison needs greater than or equal to. ‘At most 16’ includes 16, so the upper comparison needs less than or equal to.
The corrected pseudocode is: IF age >= 12 AND age <= 16 THEN display ‘Eligible’; ELSE display ‘Not eligible’.
Notice the difference between finding and explaining the bug. ‘Change the signs’ describes an edit. ‘The original conditions exclude the two permitted endpoint ages’ explains why the edit is necessary.
The input assumption also matters. This example teaches a decision condition. Handling blank entries, text or implausible ages would require additional input requirements and validation.
SECTION 3 OF 8
Choose checks that can expose the mistake
Start with a middle value such as 14. The expected result is Eligible. This checks ordinary behaviour inside the permitted range, but it will not expose the endpoint error.
Now choose the lower endpoint, 12, and a value just below it, 11. Their expected results differ. The program should accept 12 and reject 11.
Choose the upper endpoint, 16, and a value just above it, 17. It should accept 16 and reject 17.
Together, 11, 12, 14, 16 and 17 examine the outside regions, the included endpoints and an ordinary interior value. They are a useful small set for this simple integer rule.
Do not turn that list into a ritual for every task. The appropriate cases depend on the input domain and the structure of the decision. A decimal measurement, a text field and an empty list create different questions.
No small set of passing examples proves that every possible program is correct. Here the checks give targeted evidence about a simple range condition. More complex programs need broader analysis.
SECTION 4 OF 8
Trace the conditions instead of guessing
A trace follows the values and decisions step by step. For age 12 in the original program, age > 12 is false and age < 16 is true. False AND true gives false, so the program displays Not eligible.
For age 12 in the corrected program, age >= 12 is true and age <= 16 is true. True AND true gives true, so the program displays Eligible.
This trace shows exactly where the original program diverges from the requirement. It also explains why age 14 passed both versions and was a weak test for this particular bug.
A small trace record can contain the input, the first comparison, the second comparison, the combined result and the displayed output.
Predict the expected output from the written rule in a separate column. Keeping expectation separate from execution prevents the code from marking its own work.
If you cannot explain one step, stop there. Uncertainty about a comparison or Boolean operator often produces several apparently unrelated wrong answers later.
SECTION 5 OF 8
Why AND and OR cannot be swapped casually
The activity rule requires both conditions to hold. A student must be old enough and must not exceed the upper limit. That is why AND is appropriate.
Suppose someone changes the condition to age >= 12 OR age <= 16. Age 10 passes because it is at most 16. Age 18 passes because it is at least 12.
In fact, every whole-number age satisfies at least one of those two comparisons. The condition has become far too broad.
Use an ordinary-language check: does the rule require both facts, or is either fact enough? ‘A ticket is valid on Saturday or Sunday’ differs from ‘a participant has submitted the form and received approval’.
Parentheses can make combined conditions clearer. However, punctuation cannot repair a mistaken interpretation of the rule. Establish the meaning first.
When a program has several branches, test which branch is selected. A correct final number from one input can hide the fact that a different branch will fail.
SECTION 6 OF 8
Debug one cause and then check the repair
A useful debugging cycle is: reproduce the problem, locate the incorrect decision, explain the cause, make a focused correction and rerun relevant checks.
For the entry rule, preserve the original failing inputs. After changing the operators, rerun ages 12 and 16. Then rerun the outside values to make sure the repair has not expanded the range incorrectly.
Also retain an ordinary interior value. Fixing an endpoint should not break the behaviour that was already right.
Changing several unrelated lines at once makes it harder to know which change repaired the defect or introduced a new one. For a small exercise, keep the correction as focused as the evidence allows.
Do not change the written requirement just to make the existing code seem correct. If the requirement is ambiguous, clarify it before deciding which behaviour is intended.
Record the explanation in one sentence: ‘The program excluded permitted endpoint ages because it used strict comparisons.’ That sentence is more reusable than remembering only two symbols.
SECTION 7 OF 8
Practice with worked answers
Task A: a discount applies when a purchase is at least $50. The program uses amount > 50. Which simple input exposes the problem? Answer: 50. The requirement includes $50, but the strict comparison excludes it.
Task B: a game ends when lives equals zero. A student checks only a run that starts with three lives and stops after one loss. Why is that insufficient? Answer: it never reaches the decision point at zero and therefore does not test the stated ending condition.
Task C: a library permits borrowing when a member has a valid card and no overdue books. A program uses OR between those conditions. Give a case that exposes the error. Answer: a valid card with overdue books. OR may permit borrowing, whereas the rule requires both conditions.
Task D: a score band includes whole-number scores from 40 to 59. Suggest five useful checks. Answer: 39, 40, an interior value such as 50, 59 and 60. State expected bands or outputs before running them.
Extension: if scores can contain decimals, explain why testing only whole numbers gives incomplete evidence about the surrounding values. The input domain determines which nearby cases matter.
These exercises are short on purpose. Explain the expected result and the reason for choosing each input; that explanation is the learning.
SECTION 8 OF 8
For parents and tutors: inspect the thinking behind the screen
Ask the student to describe the requirement before touching the code. Then ask them to predict one accepted and one rejected input.
If they try random values, ask where the outcome should change. If they cannot explain AND, use two everyday conditions before returning to the program.
Progress becomes visible when the student can identify a failing input, trace the wrong decision and explain why the correction works.
A student who can copy a correct program may still need support interpreting a new requirement. Change the scenario while preserving the same logical structure and see whether the reasoning transfers.
Frequently asked question: does a passing test prove correctness? It proves only that the observed behaviour matched the expectation for that case. The strength of the evidence depends on the checks and the program.
Frequently asked question: should students memorise boundary values? They should learn to derive them from the rule. The numbers change; the question about included and excluded values remains useful.
Next step: take one recent school programming exercise, write three expected outputs independently and compare them with a step-by-step trace.
Sources and further reading
Curriculum references checked on 25 October 2026. All practice situations and worked answers in this article are original teaching examples.