A-Level Computer Science / Unit 12: Software Design, Testing and Evolution

12.3.2 Dry Runs, Walkthroughs and Trace Tables

🔒 Lesson slides are available to signed-in users. Sign in

12.3.2 Dry Runs, Walkthroughs and Trace Tables

A program does not need to be fully implemented before its logic can be checked. An algorithm can be followed manually using chosen data, while another developer can review its decisions, assumptions and control structures.

Dry runs, walkthroughs and trace tables help developers reason about an algorithm before or alongside computer-based testing. They are particularly useful for locating incorrect variable updates, wrong conditions, skipped data and non-terminating loops.

By the end of this section, you should be able to:

  • Explain the purposes of dry runs and walkthroughs.
  • Distinguish a dry run from a collaborative walkthrough.
  • Construct a trace table for an algorithm.
  • Follow assignments, selections and loops in the correct order.
  • Record variables, conditions, array values and outputs accurately.
  • Use a trace to identify the first point at which behaviour becomes incorrect.
  • Suggest a correction and repeat the relevant trace.

Checking Logic Without Running the Program

Manual examination can begin as soon as an algorithm has been written. It does not require a completed executable program.

Purpose How manual checking helps
Check calculations Expected values can be calculated independently and compared with the algorithm’s results.
Check control flow The reviewer can confirm which branch or loop iteration should execute.
Check initialisation Variables that begin with an incorrect or missing value can be identified.
Check boundaries Values at or near a condition boundary can be followed carefully.
Check termination The reviewer can determine whether a loop condition can eventually become false.
Check requirements A walkthrough can compare each part of the algorithm with the intended behaviour.
Common misconception: Manual checking does not prove that the final program is error-free. It provides evidence about the particular algorithm, path and data that were examined.

Dry-Running an Algorithm

Dry run: manually executing an algorithm one statement at a time using chosen input data and recording the resulting values and decisions.

During a dry run, the reviewer acts like the processor. No statement should be skipped merely because its effect appears obvious.

A systematic dry-run process

  1. Choose the input data. Select values that exercise the behaviour being investigated.
  2. Record the initial state. Include initial variable values before the first repeated step.
  3. Follow statements in execution order. Pay attention to jumps caused by selections and loops.
  4. Evaluate each condition. Record whether it is true or false.
  5. Update values immediately. A later statement must use the new value produced by an earlier assignment.
  6. Record each loop cycle. Start a new row or group of rows for each iteration.
  7. Record outputs. Compare them with independently calculated expectations.
  8. Identify the first divergence. Find the earliest point at which the actual trace differs from the intended trace.
Exam tip: A dry run is not described adequately as “reading through the code.” Mention chosen data, step-by-step execution and the recording of changing values.

Program Walkthroughs

Walkthrough: a structured review in which the author presents an algorithm or program to other people, who examine its logic and compare it with the requirements.

A walkthrough is usually collaborative. The author explains the design while reviewers ask questions, follow important paths and record possible faults or ambiguities.

Possible walkthrough roles

Role Responsibility
Author or presenter Explains the intended behaviour and guides the group through the algorithm.
Reviewer Questions assumptions, follows paths and compares the algorithm with the requirements.
Recorder Documents identified issues, unanswered questions and proposed follow-up work.
Facilitator Keeps the review focused on finding issues rather than immediately rewriting the entire solution.

What reviewers may examine

  • Does the algorithm implement every requirement?
  • Are identifiers and module purposes clear?
  • Are variables initialised before use?
  • Do selection conditions use the correct comparisons?
  • Do loops process every intended item?
  • Can repetition terminate?
  • Are invalid or unusual situations considered?
  • Do procedure calls and parameter values match their interfaces?
Common mistake: A walkthrough should review the work, not the person who wrote it. The aim is to find risks and improve the solution.

Dry Run, Walkthrough or Trace Table?

Feature Dry run Walkthrough Trace table
What it is A manual execution method A structured review method A recording format
Typical participants One developer or reviewer Author and one or more reviewers Used by whoever performs the dry run
Main focus Values and control flow for chosen data Correctness, clarity, assumptions and requirements Values, conditions, lines and outputs
Must sample data be used? Yes Often useful, but the review can be broader Normally records a particular data set
Typical result A sequence of calculated states A list of issues and actions A visible record of the manual execution
A trace table supports a dry run. It is not a separate kind of executable test.
Exam tip: To distinguish the methods, describe a dry run as manual execution with data and a walkthrough as a collaborative review of the algorithm or code.

Trace Tables

Trace table: a table used to record the changing values, conditions and outputs produced while an algorithm is followed manually.

The table should contain enough information to reconstruct the path through the algorithm. It should not contain every identifier automatically.

Possible column When it is useful
Line number When the algorithm is long or moves repeatedly between several statements.
Loop variable To identify the current iteration.
Current array element When an array is processed one item at a time.
Accumulator To record a running total or combined result.
Counter To record how often a condition has been satisfied.
Boolean condition To show why a branch was or was not taken.
Maximum or minimum To track a best-so-far value.
Output To record values or messages produced by the algorithm.
Common misconception: A trace table should not be filled by looking only at the final answer. Each row must follow from the preceding program state.

Choosing Useful Trace-Table Columns

Begin by identifying values that change or influence control flow.

Usually include

  • variables changed by assignments;
  • loop-control variables;
  • array elements used in the current iteration;
  • conditions that decide whether statements execute;
  • outputs or return values;
  • line numbers when they improve clarity.

Usually omit

  • constants that never change, unless the comparison needs to be visible;
  • variables unrelated to the path being traced;
  • long expressions that can be represented by one condition column;
  • descriptive text that does not help reconstruct execution.
Algorithm feature Useful trace columns
Running total Current item and total
Conditional counter Condition result and counter
Maximum search Current item, comparison and current maximum
Nested loop Both loop variables and relevant changing values
Procedure call Arguments, changed reference parameters and return value
Exam tip: When the question supplies a table layout, follow that layout. When designing your own, select columns that make the execution path clear.

When Should a New Row Be Added?

There is no single trace-table format for every algorithm. A new row is normally used whenever a significant part of the program state changes.

Common choices include:

  • one row for the initial values;
  • one row for each loop iteration;
  • one row for each important assignment;
  • one row whenever a condition is evaluated;
  • one row whenever output is produced.

Blank cells and unchanged values

Some trace-table conventions repeat the current value in every row. Others leave a cell blank when the value has not changed. Either approach can work when used consistently and when the meaning of a blank cell is clear.

Common mistake: Do not use a blank cell to mean both “unchanged” and “not yet assigned” in the same table.

Conditions

Write condition results as TRUE or FALSE. Do not update statements inside a branch when its condition is false.

Arrays

When an algorithm changes an array, record the element that changed or show the whole array when several positions must be followed. Recopying a large unchanged array on every row may make the table harder to read.

Worked Example: Greenhouse Moisture Summary

A greenhouse records five soil-moisture readings. The algorithm must:

  • calculate the total of the five readings;
  • count readings below 12, which require urgent watering;
  • find the highest reading.

The test data is:

Moisture = [18, 7, 24, 11, 15]

Numbered pseudocode

01 Total ← 0
02 UrgentCount ← 0
03 Highest ← Moisture[1]

04 FOR Index ← 1 TO 5
05     Total ← Total + Moisture[Index]

06     IF Moisture[Index] < 12 THEN
07         UrgentCount ← UrgentCount + 1
08     ENDIF

09     IF Moisture[Index] > Highest THEN
10         Highest ← Moisture[Index]
11     ENDIF
12 NEXT Index

13 OUTPUT Total, UrgentCount, Highest

Predict the expected result first

Result Independent calculation Expected value
Total 18 + 7 + 24 + 11 + 15 75
Urgent count Values below 12 are 7 and 11 2
Highest Largest value in the array 24

Completed trace table

Step Lines Index Moisture[Index] Total Reading < 12? UrgentCount Reading > Highest? Highest Output
Initialise 01–03 — — 0 — 0 — 18 —
Iteration 1 04–12 1 18 18 FALSE 0 FALSE 18 —
Iteration 2 04–12 2 7 25 TRUE 1 FALSE 18 —
Iteration 3 04–12 3 24 49 FALSE 1 TRUE 24 —
Iteration 4 04–12 4 11 60 TRUE 2 FALSE 24 —
Iteration 5 04–12 5 15 75 FALSE 2 FALSE 24 —
Output 13 — — 75 — 2 — 24 75, 2, 24

The traced output matches the independently predicted result. This increases confidence in the algorithm for this data, but it does not prove that every possible case is correct.

Using a Dry Run to Find the First Divergence

Consider a faulty version of the loop: 

FOR Index ← 2 TO 5
    Total ← Total + Moisture[Index]
    ...
NEXT Index

The requirement says that all five readings must be included, but the first iteration uses index 2.

Faulty trace

Iteration Index Moisture[Index] Total Expected total after this point
Initial — — 0 0
First executed cycle 2 7 7 25
Next cycle 3 24 31 49
Next cycle 4 11 42 60
Final cycle 5 15 57 75

The first divergence occurs when the loop begins with Index = 2. The reading at position 1 is never added.

The root correction is:

FOR Index ← 1 TO 5
First divergence: the earliest step at which the traced program state differs from the state required by the algorithm.
Exam tip: Do not identify only the final wrong answer. State the earliest incorrect step and explain how it causes the later result.

Walkthrough Example: Reviewing the Faulty Loop

A review team is given the requirement, the array bounds and the faulty pseudocode. The author explains that the program should process every moisture reading.

Review stage Reviewer question Finding Action
Confirm requirement How many readings must contribute to the total? All five readings Record the required index range as 1 to 5.
Inspect initialisation Are the accumulators ready before repetition? Total and UrgentCount begin at 0. No issue recorded.
Inspect loop header Which array element is visited first? The loop starts at position 2. Record that position 1 is skipped.
Check consequence Which results depend on the skipped value? The total is incorrect; other results may appear correct by coincidence. Mark this as a logic fault.
Agree correction What is the smallest root-cause correction? Change the lower bound from 2 to 1. Amend one statement.
Plan verification How will the group check the correction? Repeat the trace with the same data and other relevant arrays. Add regression tests.

The walkthrough can expose the mismatch without completing every arithmetic step. A dry run then provides numerical evidence of the consequence.

Common misconception: A walkthrough and dry run are not competing methods. They can be used together: the walkthrough raises a concern and the dry run demonstrates its effect.

Checking the Quality of a Manual Review

Check Question Weak practice
Suitable data Does the input exercise the relevant feature? Using only values that avoid every selection branch
Correct order Were statements followed in their execution order? Updating a loop variable before its current iteration finishes
Initial values Were variables recorded before use? Beginning the table after the first update
Condition accuracy Were Boolean expressions evaluated using current values? Assuming a branch without calculating its condition
Complete iterations Was every relevant loop cycle represented? Combining several cycles into one unexplained row
Independent expectation Was the required result calculated separately? Copying the traced result and calling it expected
Clear evidence Can another person reconstruct the trace? Using blanks with inconsistent meanings
Follow-up Was the correction checked? Stopping after identifying the fault
Exam tip: A useful trace table shows not only what the values became, but why the algorithm followed that route.

Interactive: Dry-Run and Walkthrough Lab

Use the widget to build the correct trace, investigate the faulty loop and follow a collaborative walkthrough. Each step reveals the evidence used to reach the conclusion.

Review mode

Build the correct trace

Follow the moisture-summary algorithm one step at a time. 

01 Total ← 0
02 UrgentCount ← 0
03 Highest ← Moisture[1]
04 FOR Index ← 1 TO 5
05     Total ← Total + Moisture[Index]
06     IF Moisture[Index] < 12 THEN
07         UrgentCount ← UrgentCount + 1
08     ENDIF
09     IF Moisture[Index] > Highest THEN
10         Highest ← Moisture[Index]
11     ENDIF
12 NEXT Index
13 OUTPUT Total, UrgentCount, Highest

Step 1 of 7

Initialise the variables

Total and UrgentCount begin at zero. Highest begins with the first array value.

Evidence: Total = 0, UrgentCount = 0, Highest = 18

Common Mistakes and Misconceptions

  • Reading instead of executing. A dry run requires values and decisions to be calculated in order.
  • Starting without initial values. The first update cannot be checked if the starting state is missing.
  • Using one row for several unexplained iterations. Each loop cycle should be visible.
  • Updating a false branch. Statements inside the branch execute only when its condition is true.
  • Using future values too early. Every statement uses the current state at that point in execution.
  • Choosing too few columns. A missing condition or counter can make the route impossible to reconstruct.
  • Choosing every possible column. Unnecessary information can obscure the values that matter.
  • Confusing a walkthrough with a dry run. A walkthrough is a collaborative review; a dry run manually executes chosen data.
  • Stopping at the final wrong answer. Locate the earliest incorrect update or path.
  • Failing to repeat the trace. The corrected algorithm should be checked using the original case and related data.

Practice

Core questions

  1. Define the term dry run.
  2. Define the term walkthrough.
  3. Explain the purpose of a trace table.
  4. Distinguish a walkthrough from a dry run.
  5. Explain why initial variable values should be recorded.
  6. Explain when a Boolean-condition column is useful.
  7. Explain why expected output should be calculated independently.
  8. Explain what is meant by the first divergence.

Scenario A: Community Bicycle Returns

LateCount ← 0
LongestDelay ← Delays[1]

FOR Position ← 1 TO 4
    IF Delays[Position] > 8 THEN
        LateCount ← LateCount + 1
    ENDIF

    IF Delays[Position] > LongestDelay THEN
        LongestDelay ← Delays[Position]
    ENDIF
NEXT Position

OUTPUT LateCount, LongestDelay

Use Delays = [4, 13, 9, 6].

  1. Predict the expected output.
  2. Choose suitable trace-table columns.
  3. Complete the trace table.
  4. State the final output.
  5. Explain what would happen if the loop ended at position 3.

Scenario B: Wildlife Camera Review

Accepted ← 0
TotalConfidence ← 0

FOR Index ← 1 TO 5
    TotalConfidence ← TotalConfidence + Confidence[Index]

    IF Confidence[Index] >= 80 THEN
        Accepted ← Accepted + 1
    ENDIF
NEXT Index

Average ← TotalConfidence / 4
OUTPUT Accepted, Average

Use Confidence = [92, 76, 84, 65, 88].

  1. Perform a dry run.
  2. Identify the first point at which the traced result becomes incorrect.
  3. Explain the root cause.
  4. Correct the algorithm.
  5. Repeat the relevant part of the trace.

Scenario C: Walkthrough Checklist

A procedure should process all six temperature readings, reject values outside the range −20 to 60 and return the number of accepted readings.

  1. Write five questions a reviewer should ask during a walkthrough.
  2. Identify the information the author should provide before the review.
  3. Suggest two useful data sets for a short manual trace.
  4. Explain what the recorder should document.
  5. Explain what should happen after a fault is corrected.
Challenge: Construct two trace tables for the same algorithm: one recording every assignment and one using one row per loop iteration. Compare their clarity and level of detail.

Review

Prompt A strong response should include
Dry run Manual statement-by-statement execution using selected data.
Walkthrough A structured review in which the author and reviewers examine the solution.
Trace table A record of changing values, conditions, iterations and outputs.
Useful columns Variables that change, loop controls, conditions, array values and outputs.
Loop tracing A separate visible record for each relevant iteration.
Finding a fault Compare expected and actual states to locate the first divergence.
After correction Repeat the original trace and check related cases.
Final exam tip: Follow the chain initial state → statement → condition → updated state → output.