Choose a program, fill in the variable values row by row, then check your answers. Use "Custom" to trace your own code. Free, no account needed — for GCSE and A Level Computer Science across all exam boards.
Choose program
Program — Pseudocode
Pseudocodecount ← 0 total ← 0 WHILE count < 4 total ← total + (count * 2) count ← count + 1 ENDWHILE OUTPUT total
Trace table
| # | count | total | |
|---|---|---|---|
| 1 |
A trace table is how you find out what an algorithm actually does, as opposed to what you think it does. You draw a column for each variable and one for output, then record a new row every time a value changes as you step through the code by hand.
You will also see this called a dry run or a desk check. They mean the same thing: the dry run is the activity, the trace table is the written record of it.
Trace table questions are among the most reliably winnable marks on any Computer Science paper, which makes the recurring errors particularly frustrating to mark.
DIV discards the remainder. Carrying a decimal through a trace where the
language would have truncated it invalidates every subsequent row.
Beyond the marks directly available, tracing is the skill that underpins debugging. A student who can dry run an algorithm reliably can find the fault in their own code without guessing, which matters for programming questions and for the NEA. It is also the quickest way to understand an unfamiliar algorithm in an exam: trace three or four iterations and the pattern usually reveals itself.
A trace table is a technique for manually working through an algorithm to record how its variables change. You draw a column for each variable, plus one for any output, then add a row every time a value changes. It lets you check what an algorithm actually does rather than what you assume it does, and it is the standard way exam questions ask you to demonstrate that understanding.
They describe the same activity. A dry run is the act of stepping through code by hand without executing it; a trace table is the written record of that dry run. Some specifications also use the term desk check. If a question asks you to dry run an algorithm, produce a trace table.
No — add a row whenever a variable changes value. Lines that only test a condition do not produce a row unless the question explicitly asks you to record the condition. Adding a row per line wastes time in an exam and makes errors more likely, though it is never actually wrong.
Yes, whenever the algorithm produces any. Marks are frequently awarded for the output sequence alone, and students who omit the column often lose those marks even when their variable tracking is perfect. If the algorithm prints anything, give it a column.
Work out whether the condition is tested before the body runs (a while loop) or after it (a repeat-until loop), because that determines whether the body executes at all and how many times. Then complete one full pass before starting the next, and keep going until the condition genuinely ends the loop — including the final check that fails.