How to Trace, Debug and Improve Algorithms in A Level Computer Science (9618)

Algorithm questions in Cambridge International AS & A Level Computer Science (9618) are not only about writing pseudocode from scratch. You may need to dry run an existing algorithm, complete a trace table, locate a fault, select test data, correct an error or amend a solution to add functionality. In the current 2026 syllabus, Paper 2 is a 2-hour, 75-mark Fundamental Problem-solving and Programming Skills paper that assesses sections 9 to 12 and requires pseudocode. Section 12.3 explicitly covers syntax, logic and run-time errors, dry runs, test methods, normal/abnormal/extreme data and amendments to existing programs. The same debugging habits also transfer directly to Paper 4, where A Level candidates write working code and submit evidence of testing.

Trace the algorithm that is written, not the algorithm you expect

Dry running means executing the algorithm manually in the exact order shown. Do not decide what the algorithm is probably trying to do and then fill the trace table with the result you expect. That hides precisely the logic errors a trace table is designed to expose. Cambridge has used explicit dry-run trace tables in Paper 2. A 2024 question, for example, asked candidates to dry run a procedure and complete columns for loop counters, characters, indexes, results and array values. The safest technique is to simulate one statement at a time and update only the values that actually change.

Click to enlarge

Initialise everything before the first iteration

Before entering a loop, write down all values assigned by declarations, input statements or initialisation lines. If an array already contains values, record the relevant starting state. If a procedure receives parameters, copy those parameter values into your working before you execute the first line. This prevents a common trace-table error: treating the first visible loop body as the start of the algorithm and forgetting that counters, accumulators or Boolean flags already have values.

Update only the columns that change

A trace table is easier to read when each row represents a meaningful state change. If Count changes but Result does not, update Count and leave Result as its current value rather than inventing a new value. If an assignment changes two dependent quantities on consecutive lines, treat those as two separate algorithm steps unless the supplied table structure clearly expects them together. Pay particular attention to arrays and indexes. Changing an array element does not automatically change every other element, and changing an index variable does not erase the old array value. Trace state, not intention.

Respect loop boundaries exactly

Most tracing errors come from control flow. For a FOR loop, identify the first value, final value and direction of iteration. For WHILE, test the condition before entering the loop body. For REPEAT...UNTIL, execute the body before testing the termination condition. If the condition changes inside the loop, update it before deciding whether another iteration occurs. When loops are nested, track the inner loop completely for the current outer-loop value before the outer variable changes. If necessary, add a rough auxiliary column to your working even if the official trace table does not include it.

Trace procedure calls and returns as separate control flow

A procedure or function call temporarily transfers control to another block of code. Track parameter values carefully. The June 2024 examiner report notes that candidates often struggle with parameters and sometimes replace them with unnecessary input statements. In a trace, use the values passed by the call; do not prompt for new values unless the pseudocode actually does so. For a function, distinguish RETURN from OUTPUT. RETURN sends a value back to the calling expression. OUTPUT displays a value. Cambridge examiner reports identify confusion between these as a recurring pseudocode problem.

Use the Cambridge pseudocode conventions

Paper 2 answers must use the published Cambridge pseudocode conventions, not Python, Java or Visual Basic syntax. The June 2024 examiner report explicitly warns that language-specific functions or methods are not acceptable when the question asks for pseudocode. The paper provides an Insert with permitted built-in functions and operators. You do not need to make pseudocode look like executable code from your favourite language. You need to communicate the algorithm in the syntax Cambridge can recognise and mark consistently.

Original trace example

Consider this short original algorithm. It counts how many values in an array are greater than 10.

Count <- 0 FOR Index <- 1 TO 4 IF Data[Index] > 10 THEN Count <- Count + 1 ENDIF NEXT Index OUTPUT Count

If Data contains 7, 14, 10 and 21, initialise Count as 0. At Index 1 the condition is false, so Count stays 0. At Index 2 it becomes 1. At Index 3 it stays 1 because 10 is not greater than 10. At Index 4 it becomes 2. The output is therefore 2. The key is that the exact comparison operator matters; silently treating 'greater than' as 'greater than or equal to' creates a logic error.

Diagnose the error type before changing code

The 2026 syllabus explicitly requires candidates to locate and identify syntax, logic and run-time errors and correct them. These are different failure modes. A syntax error breaks the rules of the notation or language. A logic error allows the program to run but produces incorrect behaviour. A run-time error occurs during execution when a valid operation reaches an invalid situation. Do not label every wrong output as a syntax error. If the code executes and gives the wrong total, the likely problem is logic. If the program attempts to access an invalid array position or divide by zero while running, that is a run-time issue.

Click to enlarge

Reproduce the fault with the smallest useful test case

Before editing a broken algorithm, find an input that reliably demonstrates the problem. A small test case is easier to trace than a huge data set. If the failure occurs only at the end of an array, use a short array that still reaches that boundary. If the problem appears when a value is empty or zero, test that exact condition. This turns debugging into a controlled experiment: one known input, one observed wrong result and one small region of code to inspect.

Choose test data deliberately

Section 12.3 requires normal, abnormal and extreme or boundary test data. Normal data are valid typical values. Boundary or extreme data test values at the limits of the allowed range. Abnormal data are invalid and should test validation or error handling. For an input that accepts integers from 1 to 100 inclusive, normal data might be 40, boundary data should include 1 and 100, and abnormal data could include 0, 101 or an inappropriate data type if the situation allows it. Do not call a value 'boundary' simply because it is unusual.

Use tracing to find logic errors

Logic errors are often easiest to locate with a trace table. Compare the expected state with the actual state after each significant line. The first point where they differ is usually close to the faulty condition, assignment or loop boundary. Typical causes include an incorrect comparison operator, an accumulator initialised to the wrong value, an off-by-one loop bound, a variable updated in the wrong order, a branch placed inside the wrong block or a RETURN statement executed too early.

Change one thing, then retest

When you think you have found the fault, make the smallest correction that addresses it. Do not rewrite an entire working procedure because one condition is wrong. Large edits create new faults and make it harder to know what actually fixed the original problem. After the correction, rerun the failing test and then rerun cases that already worked. A fix that solves one input but breaks another is not a successful fix.

Improvement questions are not always debugging questions

An algorithm can be correct and still need to be improved. The 2026 syllabus requires candidates to analyse an existing program and amend it to enhance functionality. That might mean adding validation, processing another data field, returning extra information or adapting the algorithm to a new requirement. Separate functional changes from quality improvements. Functional changes alter what the algorithm can do. Quality improvements may make the solution clearer, reduce duplication or improve robustness while preserving the required output.

Click to enlarge

Use stepwise refinement before adding a large feature

The current syllabus explicitly includes stepwise refinement. If an improvement is substantial, break it into smaller sub-problems before editing the pseudocode. For example, 'add customer validation' might become: check identifier format, search for the identifier, report invalid input, then continue only when a valid record is found. This reduces the chance of trying to solve several unrelated problems in one block and makes the final pseudocode easier to test.

Original debugging example

Suppose an algorithm is intended to find the largest value in a non-empty array but begins with Largest <- 0. This may appear to work when every array value is positive. It fails if all values are negative because 0 is never replaced. This is a logic error. A robust correction is to initialise Largest using the first array element and begin the comparison loop from the next element. The useful boundary test is not a large positive number; it is a small array containing only negative values, because that is the case that exposes the faulty assumption.

Common tracing and debugging mistakes

1. Filling a trace table from what the algorithm is supposed to do rather than executing the pseudocode line by line.
2. Skipping initialisation values before the first loop iteration.
3. Changing trace-table values in columns that the current statement did not modify.
4. Treating WHILE and REPEAT...UNTIL as if they test their conditions at the same point.
5. Ignoring parameter values and adding extra input operations inside a procedure.
6. Using programming-language syntax when the Paper 2 question asks for Cambridge pseudocode.
7. Calling every incorrect result a syntax error.
8. Testing only normal data and forgetting boundary or abnormal cases.
9. Changing several sections at once while debugging, making the successful fix impossible to identify.
10. Fixing the failing test but not retesting cases that previously worked.
11. Rewriting a whole algorithm when the question asks for one small amendment.

A reliable algorithm-question routine

1. Identify whether the task is tracing, debugging, testing or improving.
2. For a trace, record all starting values before executing the first statement.
3. Follow the actual control flow one line at a time and update only changed values.
4. For a fault, reproduce the problem with the smallest useful test case.
5. Classify the fault as syntax, logic or run-time before editing.
6. Use normal, boundary/extreme and abnormal test data where the task requires a test plan.
7. Make the smallest correction or enhancement that satisfies the requirement.
8. Use Cambridge pseudocode syntax in Paper 2 rather than language-specific constructs.
9. Retest the original failing case and cases that already worked.
10. If the change is large, refine it into smaller sub-problems before writing the final algorithm.

Put it into practice

Take one Computer Science (9618) Paper 2 algorithm question and do three separate passes. First, dry run it exactly as written. Second, identify which inputs would expose a boundary or logic problem. Third, rewrite only the smallest section needed to correct or enhance it. Then compare your pseudocode with the mark scheme and the current Cambridge pseudocode guide. Inside NeuraGeek, you can use Computer Science (9618) past-paper and topical practice to isolate algorithm, testing and pseudocode questions rather than waiting for the same mistake to reappear in a full paper.