GCSE Computer Science: What a Trace Table Question Is Actually Testing — and Why Students Lose Easy Marks

A trace table is a grid where students write down what happens inside a short piece of code, line by line, as it runs. Each column tracks a variable or the output; each row records a change. The examiner wants to see that the student has followed the code exactly as the computer would, not that they can write code themselves.

That distinction matters. Trace table questions appear in GCSE Computer Science across AQA, OCR and Edexcel, and they are often where confident programmers lose marks they should be gaining. The skill being tested is careful, patient reading — and it is a skill that can be practised.

What a trace table question looks like

A typical question gives the student a short algorithm, usually written in that board's pseudocode, and asks them to complete a table showing the value of each variable after each step, along with anything the program outputs.

Here is a small example in AQA-style pseudocode:

total ← 0
FOR i ← 1 TO 3
    total ← total + i
    OUTPUT total
ENDFOR

A correct trace table would look like this:

The code is deliberately simple. The marks come from recording every change in the right order, not from understanding anything clever.

What the examiner is actually assessing

Trace tables test whether a student can:

• Read code one instruction at a time, in the exact order given.
• Keep track of several values changing at once.
• Distinguish between what is stored in a variable and what is output to the screen.
• Resist the temptation to jump ahead or guess the final answer.

Notice what is not being tested: writing code, inventing algorithms, or spotting a shortcut. A student who can write a sorting program in Python can still lose marks here if they rush. Equally, a student who finds programming difficult can score full marks on these questions with careful practice.

This is why trace tables are such a reliable source of marks — and such a frustrating one when they go wrong.

The three mistakes that cost most marks

1. Skipping an iteration of a loop

When a loop runs several times, each pass through the loop should produce its own row in the table. Students often write down the first and last values and leave the middle rows blank, or they lose track of how many times the loop should run.

A FOR i ← 1 TO 5 loop runs five times, not four. A WHILE loop runs until its condition becomes false, which may be one iteration more or fewer than the student expects.

2. Misreading variable updates

The line total ← total + i means "take the current value of total, add i, and store the result back in total". Students sometimes:

• Add to the original starting value every time instead of the updated value.
• Update one variable but forget to carry the new value into the next row.
• Change a value before the line of code that actually changes it.

The arrow ← (or = in some pseudocode) is doing real work. Every time it appears, exactly one variable changes, and the table must show that change on that row only.

3. Confusing output with stored values

An OUTPUT or PRINT instruction displays a value but does not change any variable. Students sometimes write the output into the variable column, or write a variable's current value into the output column when nothing was actually printed.

The rule is simple: a variable column only changes when that variable is assigned a new value. The output column only gets an entry when the code says to output something.

A check parents can use without reading the code

You do not need to understand the pseudocode to help your child review their practice answers. Try this:

1. Count the rows. Ask your child how many times the loop should run and whether the table has that many rows. If they cannot explain it in one sentence, that is where the problem is.
2. Check that each row changes only what the code changed. On any given row, usually only one variable should have a new value. If several columns change at once without a clear reason, something has been rushed.
3. Compare the output column to the lines that say OUTPUT or PRINT. The number of entries in the output column should match the number of times the code outputs something.
4. Ask them to talk you through one row. Not the whole thing — just one. If they can explain row three clearly, they probably understand it. If they skip straight to the answer, they are guessing.

This is a review technique, not a teaching technique. You are not checking whether the code is correct; you are checking whether your child has been careful.

Where one-to-one feedback helps

Most tracing mistakes are consistent. A student who skips the final iteration of a loop tends to do so repeatedly. A student who confuses output with assignment usually does it in the same way each time. These patterns are hard to spot alone, because the student does not know which step they got wrong — they only see that the final answer disagrees with the mark scheme.

In one-to-one lessons, a tutor can watch a student work through a trace table in real time, pause at the exact row where the logic breaks, and ask the student to explain what they think the code is doing. That conversation often reveals a single misconception that has been costing marks across many questions.

At Luminary Tutoring, our GCSE Computer Science lessons are live and one-to-one on Microsoft Teams, and we cover trace tables in whichever pseudocode style your child's exam board uses. Lessons are recorded so your child can rewatch the moment a tricky trace was worked through.

A useful next step

Find two or three trace table questions from your child's exam board — past papers and the board's sample assessment materials are the best source — and ask your child to complete them without checking the mark scheme until the end. Then sit down together and use the four-point check above. You will quickly see whether the issue is understanding the code, keeping track of changes, or simply rushing. That tells you what kind of practice will actually help.