01 | WHAT IS A DRY RUN?

You do not always need to run a program on a computer to investigate its behaviour. You can follow an algorithm by hand, keeping track of its values as if you were executing each instruction yourself.

This is a dry run. A trace table records the changing values and important events during that execution.

Imagine reading a recipe and writing down what is in the bowl after every step. You do not jump straight to the finished cake; you follow the actual order. An algorithm trace works in the same way.

The Cambridge syllabus includes variables, outputs and user prompts when tracing an algorithm. This lesson introduces each kind of entry before combining them in a complete example.

Your task is to follow the algorithm given, even if it contains a mistake. A trace should reveal its actual behaviour, not silently repair it.

02 | PREPARE THE ALGORITHM AND INPUTS

Before tracing, identify the variable names and any starting assignments. Also identify the input values you are supposed to supply, in order.

Our first example receives two whole numbers and displays their sum. The input sequence will be 4, then 7.

1  DECLARE FirstNumber : INTEGER
2  DECLARE SecondNumber : INTEGER
3  DECLARE Total : INTEGER
4  OUTPUT "Enter the first number"
5  INPUT FirstNumber
6  OUTPUT "Enter the second number"
7  INPUT SecondNumber
8  Total ← FirstNumber + SecondNumber
9  OUTPUT "Total: ", Total

The line numbers are reference labels for this worked trace, not pseudocode instructions. They help us identify where each change occurs.

A declaration introduces a variable and its type. It does not assign zero. FirstNumber, SecondNumber and Total have no assigned numeric values yet at the start of this example.

Use a dash or a clear “not assigned” label where helpful; explain the notation rather than letting it look like a negative value.

03 | SET UP THE COLUMNS

Use a column for each relevant variable. An Event or Line column helps connect a row to the instruction, while Input and Output columns keep received and displayed information separate.

Some exam tables provide their own columns and conventions. Follow those instructions. Here we use a full-state style: each row shows the current values after that event, including unchanged values.

The dash means no value has been assigned to that variable by this algorithm yet. Blank input or output cells mean no input or output occurred in that row.

A more compact trace can record only changed values. In that style, an empty variable cell means “no new assignment recorded”, not that its previous value disappeared. The meaning of the table convention must remain clear.

04 | RECORD A PROMPT AS OUTPUT

Line 4 displays the literal text “Enter the first number”. That is a user prompt: a message telling the user what to supply.

It belongs in the output record because the algorithm communicates it. It does not change FirstNumber, and it does not itself receive the value 4.

Line 5 is INPUT FirstNumber. Only now does the first supplied input enter the algorithm, giving FirstNumber the value 4.

Keep these two events separate. OUTPUT asks or tells; INPUT receives. A prompt can appear immediately before an input, but they are not the same instruction.

A common mistake is to omit prompts because they are not final answers. If asked for all output, include the prompts in their actual order.

05 | FOLLOW THE COMPLETE ADDITION TRACE

After the first input, line 6 displays the second prompt. Line 7 receives the next supplied value, 7, into SecondNumber. Line 8 calculates 4 + 7 and stores 11 in Total.

Line 9 outputs the message and current total. It does not assign a new value to Total or change the inputs.

The full output sequence is: “Enter the first number”, then “Enter the second number”, then “Total: 11”. The received values 4 and 7 are inputs, not additional OUTPUT instructions.

The table follows execution, not just the order of variable names. It records the calculation only when that instruction is reached.

06 | ASSIGNMENTS USE CURRENT VALUES

Now trace three short assignments. Assume X and Y are declared INTEGER variables.

X ← 5
X ← X + 2
Y ← X * 3

X first becomes 5. The next instruction reads the current 5, adds 2 and stores 7 back in X. Y then becomes 7 multiplied by 3, which is 21.

Do not treat X ← X + 2 as an impossible algebraic equation. The arrow means update: evaluate the right-hand side, then store its result on the left.

When X changes, Y does not automatically recalculate. If a later line changes X to 9, the existing Y remains 21 until another instruction assigns Y a new value.

07 | LITERAL TEXT AND VARIABLE OUTPUT ARE DIFFERENT

If X holds 7, OUTPUT X displays 7. OUTPUT "X" displays the literal letter X.

OUTPUT "Value: ", X combines fixed text with the current value. Its output can be recorded as “Value: 7”. The comma separates items; it is not an extra comma that must appear in the message.

Read quotation marks carefully. A variable name inside quotes is just text; outside quotes it refers to the stored value.

Use the code’s message accurately, but do not invent additional output. Assigning seven to X does not display seven unless an OUTPUT instruction communicates it.

The system’s input interface may echo typed characters in real use. In a pseudocode trace, distinguish that from the explicit outputs the algorithm specifies.

08 | INPUTS ARE CONSUMED IN ORDER

A provided input sequence supplies values when INPUT instructions execute. The first INPUT consumes the first value, the next INPUT the second, and so on.

Suppose the algorithm performs INPUT A, INPUT B and INPUT A using inputs 4, 7 and 9. A becomes 4, B becomes 7, then A is replaced by 9.

The final state is A = 9 and B = 7. The third input does not create a new variable just because an earlier input used A already.

Do not consume an input value during an OUTPUT prompt, a comparison or an assignment. Only the executed input instruction receives the next supplied value.

If a trace reaches another INPUT but no value has been supplied for it, the run needs more input before it can continue. Do not invent a convenient value.

09 | FOLLOW THE CHOSEN PATH, NOT EVERY WRITTEN LINE

A decision can skip instructions. Trace this fragment with Mark equal to 4.

IF Mark >= 5
  THEN
    OUTPUT "Target reached"
  ELSE
    OUTPUT "Keep practising"
ENDIF

The condition Mark ≥ 5 is false, so only the ELSE output executes. Record “Keep practising”, not both messages.

With Mark equal to 5, the condition is true, so record “Target reached”. Equality is included by the comparison.

You can add a Condition result column when it helps explain a route. Some supplied tables do not require that column; you should still evaluate the condition to follow the correct path.

The next lesson develops selection and loops in depth. For now, remember that a trace follows the execution path determined by the current values.

10 | KEEP PROMPTS AND OUTPUTS IN ORDER DURING A RETRY

A short range-input loop asks for a whole-number mark until it lies from zero to fifty. Assume every supplied input is already a whole number.

DECLARE Mark : INTEGER
// Assume every supplied input is a whole number
REPEAT
    OUTPUT "Enter a mark from 0 to 50"
    INPUT Mark
    IF Mark < 0 OR Mark > 50
      THEN
        OUTPUT "Outside range"
    ENDIF
UNTIL Mark >= 0 AND Mark <= 50
OUTPUT "Accepted: ", Mark

Use input sequence 60, then 34. The first prompt appears, 60 is received and the check fails, producing “Outside range”. The loop asks again; 34 is received, passes and is output as accepted.

The same variable is reused: Mark changes from 60 to 34. The rejected value does not remain as the current Mark after the second input.

The final output is not the only output. Both prompts and the rejection message belong in the sequence. The last successful condition check exits the loop without displaying an error.

11 | TRACE THE ACTUAL ALGORITHM, INCLUDING FAULTS

Suppose the addition line is accidentally Total ← FirstNumber - SecondNumber. With inputs 4 and 7, the trace must show Total = −3, even though the apparent task was addition.

A dry run describes what the instructions do. You can separately explain that subtraction conflicts with an addition requirement, but do not put 11 into the trace for the faulty line.

Similarly, do not silently give an uninitialised total a starting zero. If the algorithm uses a value before assigning it, identify the missing initialisation or record that the value is not determined by the supplied instructions.

A trace can reveal logic errors and unclear assumptions. It is evidence for debugging, not a licence to change the algorithm while following it.

12 | DRY RUNS AND EXECUTED TESTS PROVIDE DIFFERENT EVIDENCE

A dry run predicts behaviour from the stated instructions and chosen inputs. An executed test observes a particular implementation in its environment.

The two can be compared with the requirements. If a dry run shows the wrong result, the algorithm itself needs attention. If a correct design produces a different result when implemented, investigate the implementation and setup.

Neither a single trace nor a single test covers every possible input. Choose contrasting data and important limits to exercise different behaviour.

Do not label hand-calculated predictions as actual observations from a running program. The distinction from the previous lesson still matters.

13 | A RELIABLE TRACING ROUTINE

Start with the supplied inputs and initial state. Read one executed instruction, perform exactly its operation, update the relevant value and record any input or output.

For assignments, use current values. For decisions, select the appropriate branch. For loops, return to the specified check and continue until its stopping rule is met.

Keep previous variable values unless an instruction changes them. Check quotation marks, arithmetic and output order. Do not skip the last condition check merely because the intended result already looks complete.

When asked to explain a trace entry, connect it to the instruction: “Total becomes eleven because line eight adds the current values four and seven and assigns the sum to Total.”

You should now be able to record variables, inputs, outputs and prompts without confusing their roles. Next you will practise longer paths involving selection and repeated loops.