What is test data in the context of algorithm design and problem-solving?

Test data refers to a set of inputs used to verify that an algorithm or program functions correctly. In the context of algorithm design and problem-solving, especially within the Cambridge IGCSE Computer Science curriculum, test data is crucial for validating the logic and efficiency of algorithms by ensuring they produce the expected outputs for a variety of input scenarios.

Why is test data important in the Cambridge IGCSE Computer Science curriculum?

Test data is important in the Cambridge IGCSE Computer Science curriculum because it helps students understand how to evaluate and improve their algorithms. By using test data, students can identify errors, optimize performance, and ensure their solutions are robust and reliable. This process is essential for developing problem-solving skills and understanding the practical applications of theoretical concepts.

How do you select effective test data for an algorithm?

Selecting effective test data involves choosing a variety of inputs that cover normal, boundary, and erroneous cases. Normal data tests typical inputs, boundary data tests the limits of input ranges, and erroneous data tests how the algorithm handles invalid inputs. This comprehensive approach ensures that the algorithm is thoroughly tested under different conditions, which is a key learning outcome in the Cambridge IGCSE Computer Science course.

What are the common types of test data used in algorithm testing?

The common types of test data used in algorithm testing include normal data, boundary data, and erroneous data. Normal data represents typical input values, boundary data tests the extremes of input ranges, and erroneous data includes invalid or unexpected inputs. These types help ensure that an algorithm can handle a wide range of scenarios, which is an important aspect of algorithm design and problem-solving taught in the Cambridge IGCSE Computer Science curriculum.

How can test data help in debugging an algorithm?

Test data can help in debugging an algorithm by revealing errors or unexpected behavior when the algorithm processes different inputs. By analyzing the outputs generated from test data, students can identify logical flaws or inefficiencies in their code. This process is integral to the problem-solving and algorithm design skills emphasized in the Cambridge IGCSE Computer Science curriculum, as it encourages iterative improvement and critical thinking.

Why is "Only providing normal test data" a common mistake in Test Data?

Why it happens: Students think 'data the system should accept' is enough. How to avoid it: Mark scheme expects all FOUR types — normal, boundary, abnormal, extreme — each catching a different bug class. Source: 0478 Examiner Reports 2022-2024

Why is "Confusing boundary and extreme data" a common mistake in Test Data?

Why it happens: Both involve 'edge values'. How to avoid it: BOUNDARY = at the edge AND just outside (catches off-by-one). EXTREME = largest/smallest VALID values (stress-test).

Why is "Calling a run-time error a 'logic error'" a common mistake in Test Data?

Why it happens: Both happen at run-time in some sense. How to avoid it: RUN-TIME error stops the program (crash). LOGIC error lets it finish but with wrong output. Different kinds; different recovery.

Why is "Calling a missing bracket a run-time error" a common mistake in Test Data?

Why it happens: Students conflate 'when found' with 'when caused'. How to avoid it: Missing bracket = SYNTAX error, caught by the translator BEFORE the program runs. Run-time errors only appear during execution.

Algorithm design and problem-solvingCambridge IGCSE Computer Science 0478

Test Data

Work through the notes, try the practice questions, then take the quiz. The report tells you exactly what to revise next.

Previous Next

Learn this Topic

Start with the slides for the quick version, then go deeper with the full study notes.

Short Study Notes in the form of Slides

Read the notes first. If the method in a worked example clicks, you're ready for the questions.

Short Study Notes — Test Data

Start with these resources to cover the key concepts, then work through the practice questions.

Page 1 / 0

Detailed Notes

Full prose, callouts and a recap — built for A* mastery, not just a quick scan.

Take these study notes with you

Download a branded PDF — full prose, callouts, recap and memorise list for Test Data, ready to print or save offline.

Test Data Study Notes — Cambridge IGCSE Computer Science 0478 (2026-2028 syllabus)

What kinds of test data should you actually USE? Four standard categories — normal, abnormal, boundary, extreme — each catches a different bug class. Plus the three error types: syntax, logic, run-time.

What you’ll learn

Mapped to the Cambridge IGCSE 0478 syllabus (2026-2028).

1.20.1 — Identify and use normal, abnormal, boundary and extreme test data.
1.20.2 — Distinguish syntax, logic and run-time errors.

Four test-data categories

Each one catches a different bug class.

Cambridge expects you to use FOUR types of test data — each one exposes a different kind of bug.

Normal data. Valid data the algorithm should ACCEPT and process correctly. Confirms the everyday case works. Example for an exam-mark algorithm (0-100): 67.

Boundary data. Values right at the EDGE of the valid range — both just inside and just outside. Catches off-by-one bugs.

Just INSIDE: 0 (lowest valid), 100 (highest valid).
Just OUTSIDE: -1 (just below valid), 101 (just above valid).

Abnormal / erroneous data. Data that should be REJECTED — wrong type, completely out of range, wrong format. Confirms validation works. Example: 'A' (not a number), -5, 200.

Extreme data. Largest and smallest VALID inputs — used to stress-test. For our 0-100 mark example, the extremes coincide with the boundary inside-values (0 and 100). For a 'first-name' field, extremes would be 'A' (a single letter, valid) and a very long valid name.

Four categories: normal in the middle, boundary at the edges, abnormal far outside, extreme at the largest and smallest valid values.

Cambridge tip. Mark schemes consistently expect ALL FOUR types named with examples. Listing only normal data is a 1-out-of-8 answer.

Normal — valid, processed.
Boundary — at edges, both sides.
Abnormal — rejected.
Extreme — largest/smallest valid.

See the full worked example for test data →

Three error types

Syntax, logic, run-time — caught at different times by different methods.

Syntax error. Code BREAKS the rules of the language — missing bracket, mistyped keyword, missing semicolon, wrong indentation in Python.

When caught: by the translator (compiler / interpreter) BEFORE execution.
How to fix: read the error message; the translator usually points at the line.
Example: IF X = 5 THN OUTPUT 'big' — THEN is misspelled.

Logic error. Code RUNS without complaint but produces the WRONG result.

When caught: during testing — comparing actual output against expected output.
How to fix: trace tables, breakpoints, careful reading.
Example: IF Mark > 40 THEN Pass ← TRUE ENDIF when the rule is 'pass at 40 or above' (should be >=).

Run-time error. Code passed compilation but CRASHES during execution.

When caught: the program stops with an error message at the moment the bad operation happens.
How to fix: add input validation, defensive checks, or try/catch.
Example causes: division by zero, array index out of bounds, file not found, network unreachable, stack overflow.

Cambridge tip. When asked to identify the type of error, ask 'WHEN was it caught?' — translator (syntax), test results (logic), program crash (run-time). The timing tells you the type.

Syntax — translator catches it.
Logic — testing catches it.
Run-time — execution crashes.
Use the WHEN to identify the TYPE.

See the full worked example for test data →

How it’s examined

Test data and error types appear on every Paper 2. Most-tested questions: identify and exemplify test-data types (8 marks), distinguish error types (4-6 marks). Examiner reports flag candidates who provide only normal test data as the most common loss-of-marks issue.

Sources: Cambridge IGCSE Computer Science 0478 syllabus (2026-2028); 0478 Examiner Reports 2022-2024; 0478/22 May/Jun 2023 question paper and mark scheme. Last reviewed 2026-05-09.

Master this Topic

Worked examples, formulae, definitions and the mistakes examiners flag — everything you need to push from a pass to an A*.

Take this whole topic with you

Download a branded revision sheet — worked examples, formulae, definitions and common mistakes for Test Data, ready to print or save as PDF.

Step-by-step worked examples — Test Data

Step-by-step solutions to past-paper-style questions on test data, written exactly the way a tutor would explain them at the board.

1Identify test-data types (8 marks)
Extended• Adapted from 0478/22 May/Jun 2023 Q5• test-data
Question
An algorithm accepts an exam mark from 0 to 100. Identify and describe FOUR types of test data and give an example for each. (8 marks)
Step-by-step solution
1. Step 1
  Normal data (2 marks). Values WITHIN the valid range that the system should ACCEPT. Example: 67. Confirms the algorithm processes typical inputs correctly.
2. Step 2
  Boundary data (2 marks). Values AT the EDGE of the valid range. Examples: 0 and 100 (just inside) and -1 and 101 (just outside). Catches off-by-one bugs.
3. Step 3
  Abnormal / erroneous data (2 marks). Values that should be REJECTED — wrong type, out of range, wrong format. Examples: 'A' (not a number), -5, 200. Confirms validation works.
4. Step 4
  Extreme data (2 marks). Largest / smallest plausible inputs WITHIN the valid range — used to stress-test. Examples: 0 and 100. (For some algorithms, very large or very small but valid inputs are extreme.)
Answer
Normal (typical valid), boundary (at the edges), abnormal (rejected), extreme (largest/smallest valid). Mark scheme expects ALL four kinds plus an example for each.
Examiner tip
Some boards distinguish 'boundary' from 'extreme'; others merge them. Cambridge expects boundary VALUES at the edge of validity; extreme = largest/smallest valid inputs.
2Syntax vs logic errors (4 marks)
Core• errors
Question
Distinguish between a SYNTAX error and a LOGIC error. Give one example of each. (4 marks)
Step-by-step solution
1. Step 1
  Syntax error (2 marks). The code BREAKS the rules of the language — missing bracket, mistyped keyword, missing semicolon. Caught by the translator at compile/interpret time. Example: IF X = 5 THN OUTPUT 'big' (mistyped THEN).
2. Step 2
  Logic error (2 marks). The code RUNS without complaint but produces the WRONG result. Caught by testing. Example: using + where you meant -, or < where you meant <=.
Answer
Syntax: rule-breaking code; caught by translator. Logic: code runs but answer is wrong; caught by testing.
3What is a run-time error? (4 marks)
Extended• errors, runtime
Question
Define a run-time error and give TWO common causes. (4 marks)
Step-by-step solution
1. Step 1
  Definition (2 marks). An error that occurs while the program is RUNNING — the code passed compilation but crashes or behaves unexpectedly during execution.
2. Step 2
  Causes (2 marks). (a) DIVIDE BY ZERO — attempting to divide a number by zero. (b) ARRAY INDEX OUT OF BOUNDS — trying to access element 10 of a 5-element array. (Other valid: file not found, network unreachable, stack overflow, type-conversion failure.)
Answer
Run-time = error during execution. Causes: divide by zero, array out of bounds, file not found, network failure, stack overflow.

Key Definitions and Keywords — Test Data

Definitions to memorise and the exact keywords mark schemes credit for test data answers — sharpened from recent examiner reports for the 2026 0478 sitting.

Test data
Examiner keyword
Data used to check whether an algorithm or program works correctly. Chosen deliberately to exercise different parts of the code.
Normal (valid) data
Examiner keyword
Typical data within the accepted range. Confirms the algorithm processes everyday inputs correctly.
Boundary data
Examiner keyword
Data at the EDGES of the valid range — including values just inside and just outside. Catches off-by-one errors.
Abnormal / erroneous data
Examiner keyword
Data that should be REJECTED — wrong type, out of range, wrong format. Confirms validation works.
Extreme data
Examiner keyword
Largest and smallest valid inputs — stress-test the algorithm to confirm it handles boundary-but-valid extremes.
Syntax error
Examiner keyword
An error caused by code that breaks the rules of the programming language. Caught by the translator at compile / interpret time.
Logic error
Examiner keyword
An error in the program's reasoning. Code runs without raising an error but produces the wrong result. Found through testing.
Run-time error
Examiner keyword
An error that occurs while the program is RUNNING (after passing compilation). Examples: divide by zero, array out of bounds.

Common Mistakes and Misconceptions — Test Data

The traps other students keep falling into on test data questions — taken from recent Cambridge IGCSE 0478 examiner reports and mark schemes — and how to avoid them.

✕Only providing normal test data
0478 Examiner Reports 2022-2024
Why it happens
Students think 'data the system should accept' is enough.
How to avoid it
Mark scheme expects all FOUR types — normal, boundary, abnormal, extreme — each catching a different bug class.
✕Confusing boundary and extreme data
Why it happens
Both involve 'edge values'.
How to avoid it
BOUNDARY = at the edge AND just outside (catches off-by-one). EXTREME = largest/smallest VALID values (stress-test).
✕Calling a run-time error a 'logic error'
Why it happens
Both happen at run-time in some sense.
How to avoid it
RUN-TIME error stops the program (crash). LOGIC error lets it finish but with wrong output. Different kinds; different recovery.
✕Calling a missing bracket a run-time error
Why it happens
Students conflate 'when found' with 'when caused'.
How to avoid it
Missing bracket = SYNTAX error, caught by the translator BEFORE the program runs. Run-time errors only appear during execution.

Practice questions

Exam-style questions with step-by-step worked solutions. Try one before checking the method.

Past paper style quiz

Get a report showing which sub-topics you've nailed and which ones still need work.

Test Data — frequently asked questions

The things students keep getting wrong in this sub-topic, answered.

Algorithm design and problem-solvingCambridge IGCSE Computer Science 0478

Test Data

Work through the notes, try the practice questions, then take the quiz. The report tells you exactly what to revise next.

Previous Next

Learn this Topic

Start with the slides for the quick version, then go deeper with the full study notes.

Short Study Notes in the form of Slides

Read the notes first. If the method in a worked example clicks, you're ready for the questions.

Short Study Notes — Test Data

Start with these resources to cover the key concepts, then work through the practice questions.

Page 1 / 0

Detailed Notes

Full prose, callouts and a recap — built for A* mastery, not just a quick scan.

Take these study notes with you

Download a branded PDF — full prose, callouts, recap and memorise list for Test Data, ready to print or save offline.

Test Data Study Notes — Cambridge IGCSE Computer Science 0478 (2026-2028 syllabus)

What you’ll learn

Mapped to the Cambridge IGCSE 0478 syllabus (2026-2028).

1.20.1 — Identify and use normal, abnormal, boundary and extreme test data.
1.20.2 — Distinguish syntax, logic and run-time errors.

Four test-data categories

Each one catches a different bug class.

Cambridge expects you to use FOUR types of test data — each one exposes a different kind of bug.

Normal data. Valid data the algorithm should ACCEPT and process correctly. Confirms the everyday case works. Example for an exam-mark algorithm (0-100): 67.

Boundary data. Values right at the EDGE of the valid range — both just inside and just outside. Catches off-by-one bugs.

Just INSIDE: 0 (lowest valid), 100 (highest valid).
Just OUTSIDE: -1 (just below valid), 101 (just above valid).

Abnormal / erroneous data. Data that should be REJECTED — wrong type, completely out of range, wrong format. Confirms validation works. Example: 'A' (not a number), -5, 200.

Four categories: normal in the middle, boundary at the edges, abnormal far outside, extreme at the largest and smallest valid values.

Cambridge tip. Mark schemes consistently expect ALL FOUR types named with examples. Listing only normal data is a 1-out-of-8 answer.

Normal — valid, processed.
Boundary — at edges, both sides.
Abnormal — rejected.
Extreme — largest/smallest valid.

See the full worked example for test data →

Three error types

Syntax, logic, run-time — caught at different times by different methods.

Syntax error. Code BREAKS the rules of the language — missing bracket, mistyped keyword, missing semicolon, wrong indentation in Python.

When caught: by the translator (compiler / interpreter) BEFORE execution.
How to fix: read the error message; the translator usually points at the line.
Example: IF X = 5 THN OUTPUT 'big' — THEN is misspelled.

Logic error. Code RUNS without complaint but produces the WRONG result.

When caught: during testing — comparing actual output against expected output.
How to fix: trace tables, breakpoints, careful reading.
Example: IF Mark > 40 THEN Pass ← TRUE ENDIF when the rule is 'pass at 40 or above' (should be >=).

Run-time error. Code passed compilation but CRASHES during execution.

When caught: the program stops with an error message at the moment the bad operation happens.
How to fix: add input validation, defensive checks, or try/catch.
Example causes: division by zero, array index out of bounds, file not found, network unreachable, stack overflow.

Cambridge tip. When asked to identify the type of error, ask 'WHEN was it caught?' — translator (syntax), test results (logic), program crash (run-time). The timing tells you the type.

Syntax — translator catches it.
Logic — testing catches it.
Run-time — execution crashes.
Use the WHEN to identify the TYPE.

See the full worked example for test data →

How it’s examined

Sources: Cambridge IGCSE Computer Science 0478 syllabus (2026-2028); 0478 Examiner Reports 2022-2024; 0478/22 May/Jun 2023 question paper and mark scheme. Last reviewed 2026-05-09.

Master this Topic

Worked examples, formulae, definitions and the mistakes examiners flag — everything you need to push from a pass to an A*.

Take this whole topic with you

Download a branded revision sheet — worked examples, formulae, definitions and common mistakes for Test Data, ready to print or save as PDF.

Step-by-step worked examples — Test Data

Step-by-step solutions to past-paper-style questions on test data, written exactly the way a tutor would explain them at the board.

1Identify test-data types (8 marks)
Extended• Adapted from 0478/22 May/Jun 2023 Q5• test-data
Question
An algorithm accepts an exam mark from 0 to 100. Identify and describe FOUR types of test data and give an example for each. (8 marks)
Step-by-step solution
1. Step 1
  Normal data (2 marks). Values WITHIN the valid range that the system should ACCEPT. Example: 67. Confirms the algorithm processes typical inputs correctly.
2. Step 2
  Boundary data (2 marks). Values AT the EDGE of the valid range. Examples: 0 and 100 (just inside) and -1 and 101 (just outside). Catches off-by-one bugs.
3. Step 3
  Abnormal / erroneous data (2 marks). Values that should be REJECTED — wrong type, out of range, wrong format. Examples: 'A' (not a number), -5, 200. Confirms validation works.
4. Step 4
  Extreme data (2 marks). Largest / smallest plausible inputs WITHIN the valid range — used to stress-test. Examples: 0 and 100. (For some algorithms, very large or very small but valid inputs are extreme.)
Answer
Normal (typical valid), boundary (at the edges), abnormal (rejected), extreme (largest/smallest valid). Mark scheme expects ALL four kinds plus an example for each.
Examiner tip
Some boards distinguish 'boundary' from 'extreme'; others merge them. Cambridge expects boundary VALUES at the edge of validity; extreme = largest/smallest valid inputs.
2Syntax vs logic errors (4 marks)
Core• errors
Question
Distinguish between a SYNTAX error and a LOGIC error. Give one example of each. (4 marks)
Step-by-step solution
1. Step 1
  Syntax error (2 marks). The code BREAKS the rules of the language — missing bracket, mistyped keyword, missing semicolon. Caught by the translator at compile/interpret time. Example: IF X = 5 THN OUTPUT 'big' (mistyped THEN).
2. Step 2
  Logic error (2 marks). The code RUNS without complaint but produces the WRONG result. Caught by testing. Example: using + where you meant -, or < where you meant <=.
Answer
Syntax: rule-breaking code; caught by translator. Logic: code runs but answer is wrong; caught by testing.
3What is a run-time error? (4 marks)
Extended• errors, runtime
Question
Define a run-time error and give TWO common causes. (4 marks)
Step-by-step solution
1. Step 1
  Definition (2 marks). An error that occurs while the program is RUNNING — the code passed compilation but crashes or behaves unexpectedly during execution.
2. Step 2
  Causes (2 marks). (a) DIVIDE BY ZERO — attempting to divide a number by zero. (b) ARRAY INDEX OUT OF BOUNDS — trying to access element 10 of a 5-element array. (Other valid: file not found, network unreachable, stack overflow, type-conversion failure.)
Answer
Run-time = error during execution. Causes: divide by zero, array out of bounds, file not found, network failure, stack overflow.

Key Definitions and Keywords — Test Data

Definitions to memorise and the exact keywords mark schemes credit for test data answers — sharpened from recent examiner reports for the 2026 0478 sitting.

Test data
Examiner keyword
Data used to check whether an algorithm or program works correctly. Chosen deliberately to exercise different parts of the code.
Normal (valid) data
Examiner keyword
Typical data within the accepted range. Confirms the algorithm processes everyday inputs correctly.
Boundary data
Examiner keyword
Data at the EDGES of the valid range — including values just inside and just outside. Catches off-by-one errors.
Abnormal / erroneous data
Examiner keyword
Data that should be REJECTED — wrong type, out of range, wrong format. Confirms validation works.
Extreme data
Examiner keyword
Largest and smallest valid inputs — stress-test the algorithm to confirm it handles boundary-but-valid extremes.
Syntax error
Examiner keyword
An error caused by code that breaks the rules of the programming language. Caught by the translator at compile / interpret time.
Logic error
Examiner keyword
An error in the program's reasoning. Code runs without raising an error but produces the wrong result. Found through testing.
Run-time error
Examiner keyword
An error that occurs while the program is RUNNING (after passing compilation). Examples: divide by zero, array out of bounds.

Common Mistakes and Misconceptions — Test Data

The traps other students keep falling into on test data questions — taken from recent Cambridge IGCSE 0478 examiner reports and mark schemes — and how to avoid them.

✕Only providing normal test data
0478 Examiner Reports 2022-2024
Why it happens
Students think 'data the system should accept' is enough.
How to avoid it
Mark scheme expects all FOUR types — normal, boundary, abnormal, extreme — each catching a different bug class.
✕Confusing boundary and extreme data
Why it happens
Both involve 'edge values'.
How to avoid it
BOUNDARY = at the edge AND just outside (catches off-by-one). EXTREME = largest/smallest VALID values (stress-test).
✕Calling a run-time error a 'logic error'
Why it happens
Both happen at run-time in some sense.
How to avoid it
RUN-TIME error stops the program (crash). LOGIC error lets it finish but with wrong output. Different kinds; different recovery.
✕Calling a missing bracket a run-time error
Why it happens
Students conflate 'when found' with 'when caused'.
How to avoid it
Missing bracket = SYNTAX error, caught by the translator BEFORE the program runs. Run-time errors only appear during execution.

Practice questions

Exam-style questions with step-by-step worked solutions. Try one before checking the method.

Past paper style quiz

Get a report showing which sub-topics you've nailed and which ones still need work.

Test Data — frequently asked questions

The things students keep getting wrong in this sub-topic, answered.

Test Data

Short Study Notes in the form of Slides

Short Study Notes — Test Data

Detailed Notes

What you’ll learn

How it’s examined

1Identify test-data types (8 marks)

2Syntax vs logic errors (4 marks)

3What is a run-time error? (4 marks)

Test data

Normal (valid) data

Boundary data

Abnormal / erroneous data

Extreme data

Syntax error

Logic error

Run-time error

✕Only providing normal test data

✕Confusing boundary and extreme data

✕Calling a run-time error a 'logic error'

✕Calling a missing bracket a run-time error

Practice questions

Past paper style quiz

Assess your understanding

Test Data — frequently asked questions

Test Data

Short Study Notes in the form of Slides

Short Study Notes — Test Data

Detailed Notes

What you’ll learn

How it’s examined

1Identify test-data types (8 marks)

2Syntax vs logic errors (4 marks)

3What is a run-time error? (4 marks)

Test data

Normal (valid) data

Boundary data

Abnormal / erroneous data

Extreme data

Syntax error

Logic error

Run-time error

✕Only providing normal test data

✕Confusing boundary and extreme data

✕Calling a run-time error a 'logic error'

✕Calling a missing bracket a run-time error

Practice questions

Past paper style quiz

Assess your understanding

Test Data — frequently asked questions