[7.6–7] Test data & tracing

[7.6–7] Test data & tracing: choosing data and completing trace tables

Testing shows whether a solution behaves as intended. For IGCSE, you must be able to suggest and apply suitable test data and to complete trace tables that track the values of variables step by step. This page explains the key test data categories: normal, abnormal, extreme, and boundary. It also shows how to use trace tables to follow an algorithm through selections and loops so that you can predict outputs confidently and spot logic errors such as off-by-one mistakes.

Why we categorise test data

A single test rarely proves correctness. Grouping tests into categories ensures you cover typical user behaviour and edge cases that often break programmes. Each category has a purpose:

Category	Purpose	Typical examples	Expected outcome
Normal	Shows routine, sensible inputs are processed correctly	Age 14 in a 10–18 system; mark 72 when 0–100 allowed	Accepted and correctly handled
Abnormal	Shows invalid inputs are rejected safely	Age = "ten"; mark = -3; empty name	Rejected with a helpful message
Extreme	Shows the system copes with the largest/smallest sensible values	Mark = 0, Mark = 100; queue length exactly full	Accepted and processed correctly
Boundary	Targets values just at/around limits where mistakes occur	Age = 9, 10, 18, 19 when 10–18 inclusive; length = 7, 8, 9	At or within limits accepted; outside rejected

In exam answers, state the value and reason (e.g. "Boundary: 10 because the lower limit is 10 and should be accepted"). Avoid vague phrases like "sensible" without explaining why.

Designing test sets for a single rule

Most validation and logic rules can be tested using a small, purposeful set of values. The tabs below show how to build a concise test set for a range rule (10–18 inclusive). Notice how boundary and extreme cases are different: extremes are the largest/smallest valid values; boundaries include just-outside values too.

Normal examples: 12, 14, 17. These demonstrate everyday operation without stressing the limits. Use two or three values spread across the range to show consistent behaviour.

Boundary set: 9 (reject), 10 (accept), 18 (accept), 19 (reject). This explicitly proves the lower and upper limits are correct and that just-outside values are handled safely.

Extreme values: 10 and 18, because the rule is inclusive. These are still valid and must be accepted and processed properly. If inclusive/exclusive is unclear, state it in your answer.

Combining rules: building minimal but effective test suites

Real inputs often have more than one rule (e.g. presence + type + range). A good test suite covers each rule without exploding into dozens of cases. Consider an exam mark: required, integer, 0–100 inclusive.

Choose typical integers inside range, e.g. 45, 72. These confirm ordinary marking works and calculations like averaging behave as expected.

One test per violated rule: blank (presence), "eighty" (type), 103 (range high), -2 (range low). Each should be rejected with a clear message so the user can fix the problem.

Boundary and extreme together: -1 (reject), 0 (accept), 100 (accept), 101 (reject). This proves both edges and the behaviour just outside them.

Trace tables: following an algorithm step by step

A trace table is a grid that shows how variable values change as each step of an algorithm runs. It helps you predict outputs without executing code on a computer. To complete a trace table, list the step number or line, write down variables of interest as column headings, and then fill in the new values after each step. Show when conditions are tested and when loops repeat.

What to include in a trace table

Inputs and initial values before the first step.
Variables that change, especially accumulators and loop counters.
Decisions: record whether conditions evaluated to true or false.
Outputs when they occur.

Track each assignment in order. If total starts at 0 and you add 5 then 3, the table shows total becoming 5 then 8, finishing with output 8. Because there is no branching, the path is linear and easy to follow.

Include a column for the condition result. Example: IF mark >= 50 THEN pass ← true ELSE pass ← false. For input 47 record the condition as false and set pass to false. For 50 record true and set pass to true. This prevents mistakes around the comparison operator.

Show the counter before and after each iteration, and the accumulator's new value. If the loop runs from 1 to 3, your table should have three rows for the body, not four. Many errors arise from including an extra iteration or missing the last one.

Deep Dive: Equivalence partitions vs boundary analysis

Equivalence partitioning groups inputs that your programme treats the same way (e.g. all ages 10–18 form one valid partition). Testing one value from each partition is usually enough to show typical behaviour. Boundary value analysis then targets values where behaviour changes, such as 9/10 and 18/19. Combining both techniques gives high confidence with few tests.

Common pitfalls (and how to avoid them)

Confusing boundary and extreme: Extreme values are the largest/smallest valid ones; boundary testing also includes just-outside values.
Forgetting inclusivity: Clearly state whether limits are inclusive or exclusive to avoid rejecting valid extremes.
Incomplete trace tables: Do not skip iterations or forget to record condition outcomes. Label each pass clearly.
Too many similar tests: Choose representative normal values and focus effort on boundaries and rule combinations.
Unclear expected results: When proposing test data, always state the expected outcome (accept/reject and the output or message).

Key terminology

Normal data: typical, sensible inputs that should be accepted.
Abnormal data: invalid inputs that should be rejected safely.
Extreme data: largest and smallest valid inputs for a rule.
Boundary data: values at and just outside limits where behaviour changes.
Equivalence partition: a set of inputs treated the same by the programme.
Trace table: a step-by-step record of variable values as an algorithm runs.

Key Takeaways

Use normal, abnormal, extreme, and boundary categories to design focused, efficient test sets.
Always state the expected result for each test to show your understanding.
Boundary tests should include both the limits and just-outside values to catch off-by-one errors.
Trace tables track variable changes, decisions, and iterations to predict outputs accurately.
Combine equivalence partitioning with boundary analysis for high coverage with few tests.