G3 Computing tuition can help your child find a logic error by starting at the first unexpected output and tracing backwards to the earliest variable, condition or update that became wrong. The useful habit is not random editing; it is a short evidence trail from symptom to cause.
Try this first: give your child a small program that runs but prints the wrong total. Ask them to circle the first output that differs from the expected result, then write the values that must have produced it. If they immediately rewrite several lines, the missing skill is controlled debugging.
G3 is a subject level, not Posting Group 3. This guide follows the 2027 SEC G3 Computing syllabus K349. Confirm the student’s actual subject entry and the school’s software arrangements; K349 includes Python and spreadsheet work, but schools remain responsible for examination administration.
In this guide
Diagnose the error before editing
A program can fail in different ways. A syntax error may prevent it from running. A run-time error may interrupt execution. A logic error is quieter: the program runs, but its behaviour or output is wrong. Treating all three as “my code is broken” leads to noisy trial and error.
Tuition should first ask what the program was meant to do, what input was used, what output was expected and what actually happened. Without that four-part record, a learner may “fix” a line that was correct or accidentally create a second error.
- Specification gap: the intended behaviour is unclear.
- Trace gap: the child skips variable updates.
- Condition gap: a branch is taken at the wrong time.
- Boundary gap: a loop starts or stops one step too early.
- State gap: an old value is reused instead of the new one.
Find the first wrong state
The last wrong answer is often far from the cause. If a total is wrong after ten loop iterations, the decisive clue may be the first iteration where the running total diverged. That is why a trace table and carefully placed print statements are more useful than staring at the final line.
A learner can compare expected and actual values at checkpoints: before a loop, after each update, before a condition and immediately after a function returns. The first mismatch narrows the search. Everything before it has passed that particular test; the cause is likely at or just upstream of the change.
This also teaches restraint. Good debugging changes one justified thing, reruns the same test and records the result. Multiple simultaneous edits destroy the evidence trail.
Backtrack one dependency at a time
Backtracking means asking where the wrong value came from. If average is wrong, inspect total and count. If total is wrong, inspect the update expression and the values added. If a value should never have been added, inspect the condition that admitted it.
The process moves through dependencies, not simply upward through lines of code. Functions, branches and loops may mean that the previous executed statement is not the previous printed line. A short manual dry run makes the actual path visible.
After locating a plausible cause, the student should predict what a correction will change. “I think changing <= to < will remove the extra iteration” is testable. “Let me try this” is not yet a debugging explanation.
Work through a small example
Consider a tutor-created program that should add the numbers 1 to 4 but prints 15. A trace shows totals of 1, 3, 6, 10 and then 15. The first four states are correct; the unexpected fifth update adds 5.
Backtracking from 15 points to the loop condition. If the counter begins at 1 and the loop continues while counter <= 5, the program is doing exactly what the code says, not what the specification intended. The smallest defensible correction is to stop at 4, then rerun normal and boundary cases.
The learning is larger than this example. The child has linked symptom, trace evidence, executed path, cause hypothesis, minimal correction and retest. That sequence transfers to longer programs.
Use a three-student debugging review
If the provider genuinely teaches K349, a three-student lesson can make hidden reasoning audible. One learner states the intended behaviour, one traces the executed values and one challenges every proposed edit: “Which observation makes you think that line is the cause?”
Roles rotate across unrelated practice programs. Each learner then receives a fresh bug and must debug it independently. The group supplies comparison and questions; it does not become a shared answer-writing exercise.
This follows the immutable small-group teaching reference: identify the first unstable reasoning move, give focused guidance, reduce prompts and verify independent application.
Align with K349
The official 2027 SEC G3 Computing syllabus K349 explicitly requires students to locate logic errors by backtracking from unexpected behaviour. It also names manual dry runs, trace tables, selected print statements, incremental testing, isolated testing and normal, error and boundary test cases.
K349 has a 60% written paper and a 40% lab-based paper. The lab paper lasts 2 hours 30 minutes and uses a spreadsheet, Python and JupyterLab. Debugging therefore belongs to both conceptual explanation and practical execution.
Check the SEAB 2027 G3 school-candidate directory for the current document and confirm the student’s school arrangements.
Know what tuition cannot replace
A tutor can teach debugging with separate practice programs, but should not complete school-controlled assessed work or supply a ready-made solution the student cannot explain. Code ownership matters: the learner should understand every variable, condition and correction submitted under their name.
Tuition also cannot substitute for the school’s examination software, network controls or submission instructions. Practise saving and checking work in the environment the school specifies.
Finally, not every unexpected result is caused by one line. Requirements may be misunderstood, input may be invalid or several small errors may interact. The method still helps because it makes each claim testable.
Check independent progress
Give your child a short unfamiliar program, one input and an expected output. Progress is visible when the learner identifies the first mismatch, names the values feeding it, predicts a minimal correction and retests without being told which line to change.
- The expected behaviour is stated before editing.
- The first wrong state is identified.
- A trace or print statement supplies evidence.
- One dependency is followed backwards at a time.
- The proposed correction includes a prediction.
- The same case and a boundary case are rerun.
- The learner can explain why the corrected program now works.
Continue with tracing loops without skipping updates, choosing test data and the series directory.
