A program runs without crashing but gives the wrong result. A student changes several lines, tries again and hopes the next version works. Debugging becomes more useful when each change answers a question about what went wrong.
In school Computing, tracing and testing can turn a disappointing output into evidence. This guide follows a small fictional scoring rule without depending on a particular programming language or assuming every school offers the same Computing course.
Methodist Girls’ School’s Computer Studies page includes designing, testing and debugging among its computing practices. Its programme is school-specific. The exercise below is independent eduKate guidance, not an assessed assignment or an official syllabus checklist.
Find your next learning step
Write the intended behaviour before changing anything · Trace a small case step by step · Change one suspected cause and test again · Choose tests that challenge the rule · Explain the fix and preserve ownership of the work
Imagine a fictional program awarding a badge to a player who earns at least 10 points. A score of 9 should not earn the badge; scores of 10 and 11 should. These examples make the rule concrete.
Now suppose the program awards the badge only when the score is greater than 10. It may appear correct for many inputs while mishandling exactly 10.
Before editing, record the input, expected output and actual output for the failing case. “Score 10 should earn a badge, but the program says no” is a specific problem statement.
Separate what the program is intended to do from what the student assumes it does. The task brief, not the current code, defines the requirement.
If the requirement itself is unclear, clarify it. Debugging cannot establish which of two ambiguous rules the teacher intended.
Use the tracing method taught in class. Follow the relevant value through the program and identify the decision that produces the unexpected result.
In the badge example, compare the condition with the wording “at least”. The boundary value is included by the requirement but excluded by a strict greater-than comparison.
That gives a reason to inspect the comparison rather than unrelated parts of the program. The first useful change is the one supported by the trace.
Students should distinguish a syntax problem from a logic problem. A language may reject malformed instructions; valid instructions can still implement the wrong rule. The kind of evidence needed differs.
Parents do not need to know the language to ask, “What did you expect here, and what happened instead?” That question helps the student make their own reasoning explicit.
Make a focused revision. In the fictional example, the comparison must include the threshold. Then rerun the test that previously failed.
A passing result at 10 is encouraging but incomplete. Check 9 and 11 as well, because a change should preserve the intended behaviour on either side of the boundary.
Use the task’s permitted input conditions. Do not quietly change the requirement or exclude an inconvenient valid case to make a test pass.
Keep a brief record of the change and its reason. A student should be able to explain the correction without relying on the fact that the screen now looks right.
If several lines are changed simultaneously, it becomes harder to identify which change fixed the problem or introduced another one. Focus keeps the next observation interpretable.
Try cases that exercise different parts of the requirement, not only several inputs that behave in the same way. Boundary cases can be particularly revealing when the task uses a threshold.
Where an assignment includes invalid inputs, follow its stated handling requirements and the teacher’s testing guidance. Do not assume every school task requires the same validation strategy.
Ask what a successful test establishes. One correct result shows that the program handled that case; it does not prove every possible case is correct.
For a larger task, break the problem into smaller checks. Does the input arrive as expected? Is the calculation correct? Does the display represent the result accurately?
The evidence habit connects with our Geography fieldwork guide: the conclusion should match what the observations can support, even though the subject methods differ.
After the program behaves as required, ask the student to summarise the error, the evidence and the correction. That explanation makes the learning portable to another program.
Use help within the assignment’s rules. If a tool or another person supplies a complete solution, the student may lose the opportunity to locate and understand the misunderstanding. Follow any rules on collaboration, attribution and AI use.
For the school context, explore our Methodist Girls’ School (Secondary) guide. For subject planning, consult the subject-combination guide and the current MOE curriculum directory.
An interest in debugging may reveal enjoyment of precise reasoning and systematic investigation. Treat that as something to explore across future courses, not a guarantee of admission or a fixed career identity.
Does finding an error mean the student is poor at Computing? A discovered error gives the student something specific to investigate. The useful question is whether they can move from guessing to explaining and testing.
The next time a program gives the wrong output, begin with a smaller question: “Where does the actual behaviour first stop matching the intended behaviour?”
Sources checked 17 October 2026. Independent eduKate educational guidance. Confirm current school and assessment requirements with the relevant institution. Named-school examples describe their published provision; teaching exercises are illustrative.