SLIDE 1
CSZone.co.uk
Click to reveal · Arrow keys also work
OCR J277 · Component 2 · Topic 2.3.2

Producing Robust Programs
Testing

Iterative & final testing · Test data types · Trace tables — making sure programs work correctly

CSZone OCR GCSE Computer Science J277
Learning Objectives

By the end of this video you will be able to...

Explain the purpose of testing — why programs must be tested before release and what categories of error testing aims to find
Describe the difference between iterative testing (testing at each stage of development) and final/terminal testing (testing the complete, finished program)
Identify and give examples of the three types of test data: normal (data that should be accepted), boundary (data at the extreme edges), and erroneous (data that should be rejected)
Construct and complete a trace table — a dry run that tracks the value of every variable at each step of a program's execution
Apply all three types of test data to a given scenario — choosing the right examples for a specific program and explaining why each category matters
⚡ Testing is not an optional step — it is how programmers confirm their program does what it is supposed to do, and that it handles unexpected input without breaking.
Purpose of Testing

Why do programs need to be tested?

DEFINITION
Testing is the process of running a program with carefully chosen inputs to confirm it produces the correct outputs, handles unexpected input gracefully, and meets its original requirements — before it is released to users.
THREE CATEGORIES OF ERROR TESTING FINDS
Syntax errors — code that breaks the rules of the language (e.g. missing brackets, misspelled keywords). Caught by the interpreter/compiler before the program runs.
Logic errors — the program runs without crashing but produces the wrong result (e.g. wrong formula, off-by-one loop). Only found by testing with known expected outputs.
Runtime errors — the program crashes during execution (e.g. dividing by zero, converting "abc" to an integer). Found when the program is run with certain inputs.
WHY LOGIC ERRORS ARE THE HARDEST
Syntax errors stop the program before it runs — the interpreter tells you. Logic errors are invisible until you test with the right input and check the output against what you expected. The only way to find them is thorough testing.
WHAT TESTING CONFIRMS
CorrectnessDoes the program produce the right output for valid input?
RobustnessDoes the program handle invalid input without crashing?
ReliabilityDoes the program produce consistent, predictable results?
CompletenessDoes the program meet all its original requirements?
IN THE EXAM
Questions may ask you to explain the purpose of testing, identify the type of error in a given scenario, or describe why a specific type of test data is used. Knowing the three error types — syntax, logic, runtime — and what each one means is essential.
Types of Testing

Iterative testing vs final/terminal testing

ITERATIVE TESTING
Iterative testing is testing that happens continuously during development — after each module, subroutine, or section of code is written. Errors are found and fixed immediately, before the next section is built on top.
Test each subroutine or section as soon as it's written
Errors are found and fixed while the code is fresh in mind
Prevents errors compounding — a bug in module 1 won't break module 2, 3, and 4
Also called: white-box testing (the tester can see and knows the code)
EXAMPLE — ITERATIVE
A developer writes a calculateTotal() function. Before writing the rest of the program, they test it with several inputs and confirm the output is correct. Then they move on to writing the next function.
FINAL / TERMINAL TESTING
Final testing (also called terminal testing) happens at the end of development, when the complete program is tested as a whole. This checks that all modules work together correctly and that the program meets its original requirements.
Tests the complete, finished program end-to-end
Checks that modules work together correctly (integration)
May involve the client or end users testing the software
Also called: black-box testing (testers don't need to know the internal code)
COMPARISON
FeatureIterativeFinal
When?During developmentEnd of development
What's tested?Individual modulesComplete program
Who tests?DeveloperDeveloper / client / user
Test Data

The three types of test data

THREE TYPES — OCR SPEC
TypeDefinitionExpected result
NormalValid data the program should accept and process correctlyAccepted, correct output
BoundaryData at the extreme limits of what is and isn't acceptedVaries (in/out of range)
ErroneousInvalid data the program should reject or handle gracefullyRejected, error message
SCENARIO: SCORE MUST BE 0 TO 100
TypeExamples
Normal25, 50, 73 — well within range
Boundary−1, 0, 1, 99, 100, 101 — at the edges
Erroneous−50, 200, "abc", "" — clearly invalid
WHY ALL THREE ARE NEEDED
NORMAL DATA
Confirms the program works correctly for everyday, expected inputs — the most common case. If normal data fails, the program is fundamentally broken.
BOUNDARY DATA
Tests the exact edges of validation logic — where off-by-one errors hide. A program that works for 50 may fail silently at exactly 0 or exactly 100.
ERRONEOUS DATA
Confirms defensive design works — the program correctly rejects invalid input and doesn't crash. Without this, the program is not robust.
COMPLETE TEST PLAN
A proper test plan uses all three types together. Normal data proves correctness. Boundary data catches edge cases. Erroneous data proves robustness. Testing with only normal data misses most real-world failures.
Test Data

Normal test data

DEFINITION
Normal test data (also called valid data) is data that the program should accept and process correctly. It represents typical, everyday inputs from a real user. The expected result is always a correct output, with no errors.
NORMAL DATA — EXAMPLES BY PROGRAM TYPE
ProgramNormal test data
Score 0-10045, 72, 88
Age 0-12016, 35, 62
Username (3-20 chars)"alice", "johndoe99"
Login (user: "admin")"admin" + "pass1"
WHAT NORMAL DATA TESTS
Normal data checks the happy path — the main intended use of the program. If normal data produces wrong output, the core logic is broken. This must always be tested first. If normal data fails, there is no point testing the other types yet.
EXAMPLE — TEST TABLE
Program: accepts scores 0-100, calculates grade
Test #InputTypeExpected output
150NormalGrade C
285NormalGrade A
330NormalGrade F
HOW MANY NORMAL TEST CASES?
Choose normal data that covers the main branches of the program — one value for each grade boundary, one value from each section of an IF-ELSE chain. Don't just test one value and assume the program works for all valid inputs.
Test Data

Boundary test data

DEFINITION
Boundary test data (also called edge case data) tests values at the extreme limits of the valid range — the points where the program transitions between accepting and rejecting input. This is where off-by-one errors in validation logic hide.
THE FOUR BOUNDARY VALUES — RANGE 1 TO 10
0
JUST BELOW
rejected
1
LOWER BOUNDARY
accepted
···
10
UPPER BOUNDARY
accepted
11
JUST ABOVE
rejected
WHY BOUNDARIES EXPOSE BUGS
A validation condition written as score < 100 instead of score <= 100 would reject 100 — a valid score. That bug only shows up when you test with exactly 100. Testing 50 would pass and miss it entirely.
BOUNDARY TEST TABLE — SCORE 0 TO 100
InputDescriptionExpected
−1Just below lower boundaryRejected
0Lower boundaryAccepted
1Just above lower boundaryAccepted
99Just below upper boundaryAccepted
100Upper boundaryAccepted
101Just above upper boundaryRejected
EXAM ANSWER RULE
When asked for boundary data for a range of a to b — give values at a−1, a, b, and b+1. These four values test both edges of the boundary. For a 0-to-100 range: −1, 0, 100, and 101.
Test Data

Erroneous test data

DEFINITION
Erroneous test data (also called invalid data) is data that should never be accepted by the program. The expected result is always rejection — an error message or re-prompt. If erroneous data is accepted, the defensive design has failed.
ERRONEOUS DATA — EXAMPLES BY PROGRAM TYPE
ProgramErroneous examples
Score 0-100−50, 150, "abc", "" (empty)
Age 0-120−5, 200, "twenty", ""
Username (3-20 chars)"ab" (too short), 30-char string (too long)
LoginWrong username, wrong password, both wrong
THREE KINDS OF ERRONEOUS DATA
Wrong type — a string where a number is expected ("hello", "abc")
Out of range — a number that is clearly too large or too small (−999, 9999)
Empty input — pressing Enter without typing anything ("")
ERRONEOUS TEST TABLE — SCORE 0 TO 100
InputWhy erroneousExpected
−50Far below rangeError message, re-prompt
200Far above rangeError message, re-prompt
"abc"Wrong data typeError message, re-prompt
""Empty inputError message, re-prompt
WHY ERRONEOUS DATA MATTERS
Real users type the wrong thing. They accidentally enter letters in number fields, press Enter on blank inputs, or type values that make no sense. A program that crashes on any of these has failed its defensive design. Erroneous testing verifies the defensive design actually works.
Trace Tables

Trace tables — tracking program execution

WHAT IS A TRACE TABLE?
A trace table is a manual dry run of a program — you execute the code yourself, one line at a time, recording the value of every variable after each step. It is used to find logic errors, verify program behaviour, and understand the execution of loops.
HOW TO SET UP A TRACE TABLE
One column per variable — and one column for output
One row per step — a new row each time a variable changes value
Write the new value only in the column of the variable that changed
Leave all other cells blank if the value didn't change on that step
WHAT TRACE TABLES FIND
Off-by-one errors in loop conditions. Variables with wrong initial values. Logic errors in conditional branches. Loops that run the wrong number of times. All logic errors that the interpreter cannot catch for you.
SIMPLE EXAMPLE — STEP BY STEP
x ← 1 total ← 0 WHILE x <= 3 DO total ← total + x x ← x + 1 ENDWHILE print(total)
xtotaloutput
1——
—0—
—1—
2——
—3—
3——
—6—
4——
——6
READING THE TABLE
Each row shows one change. When x becomes 4, the WHILE condition (x ≤ 3) is false, so the loop ends. x = 4 is recorded but the loop body doesn't run again — hence total stays at 6, and print(total) outputs 6.
Worked Example

Trace table — worked example with a FOR loop

PROGRAM — CALCULATE AVERAGE
Trace this program and record all variable values at each step.
total ← 0 FOR i = 1 TO 4 total ← total + i NEXT i avg ← total / 4 print(avg)
STEP-BY-STEP TRACE
The FOR loop runs for i = 1, 2, 3, 4. Each iteration adds i to total.
totaliavgoutput
0———
—1——
1———
—2——
3———
—3——
6———
—4——
10———
——2.5—
———2.5
WALKING THROUGH THE TRACE
Init: total ← 0. Before the loop.
i=1: total = 0+1 = 1
i=2: total = 1+2 = 3
i=3: total = 3+3 = 6
i=4: total = 6+4 = 10
After loop: avg = 10 / 4 = 2.5. Output: 2.5
TRACE TABLE TIPS
Only write in the column of the variable that changed — leave others blank
Check loop condition on each iteration — if false, the loop exits
Output column only gets a value when a print statement executes
Exam Practice

Testing — exam questions

Question 1 — 1 mark
State what is meant by boundary test data.
Answer — Q1
Boundary test data is data at the extreme limits of the valid range — values at the exact edges of what is and is not accepted. It tests whether the program correctly accepts values at the boundary and correctly rejects values just outside it. (1 mark)
Question 2 — 3 marks
A program asks the user to enter a mark between 1 and 10 inclusive. Give one example each of: normal test data, boundary test data, and erroneous test data for this program.
Answer — Q2
Normal Any value from 2 to 9, e.g. 5 — a typical valid input. [1]

Boundary 1, 0, 10, or 11 — at the edge of the valid range, e.g. 1 (just accepted) or 0 (just rejected). [1]

Erroneous e.g. −5, 99, "abc", or "" — clearly invalid and should be rejected. [1]
Question 3 — 4 marks
Trace through the program below and complete the trace table.

a ← 2
b ← 0
FOR i = 1 TO 3
    b ← b + a
    a ← a + 1
NEXT i
print(b)
iaboutput
—2——
——0—
???—
???—
???—
———?
Exam Answers

Question 3 — completed trace table and mark scheme

Q3 — COMPLETED TRACE TABLE
iaboutput
—2——
——0—
1—2—
—3——
2—5—
—4——
3—9—
—5——
———9
i=1: b=0+2=2, a=3 · i=2: b=2+3=5, a=4 · i=3: b=5+4=9, a=5 · print(9)
MARKS BREAKDOWN
[1] — i=1: b becomes 2, a becomes 3
[1] — i=2: b becomes 5, a becomes 4
[1] — i=3: b becomes 9, a becomes 5
[1] — correct output: 9
TEST DATA TYPES — QUICK REFERENCE
TypeFor range 1–10Expected
Normal5Accepted ✓
Boundary0, 1, 10, 111,10: ✓ · 0,11: ✗
Erroneous−50, 99, "abc"Rejected ✗
ITERATIVE VS FINAL — QUICK REFERENCE
TypeWhenWhat
IterativeDuring developmentEach module/subroutine
FinalEnd of developmentComplete program
⚡ Exam tip: in trace table questions, work one line at a time — don't try to skip ahead. Check the loop condition at the start of every iteration and stop the moment it's false. Never guess a final value — trace every step.
Common Mistakes

Common mistakes — avoid these in the exam

MISTAKE 1 — Giving only normal data when boundary is asked for
When asked for boundary test data, students give a value well within the range — e.g. 50 for a 0-to-100 program. That is normal data. Boundary data must be at the edges: the exact limits (0 and 100) and the values just outside them (−1 and 101)
✓ For a range a to b: give a−1, a, b, and b+1 as your four boundary values
MISTAKE 2 — Confusing erroneous with boundary data
Students often confuse "just outside the boundary" (boundary data) with "clearly invalid" (erroneous data). The value 101 for a 0-to-100 range is boundary data — it's just one step outside. The value 999 or "abc" is erroneous — it's far outside or the wrong type entirely
✓ Boundary = at the edge (one step in or one step out). Erroneous = clearly invalid, wrong type, or far out of range
MISTAKE 3 — Filling in unchanged cells in a trace table
Students write the current value of every variable in every row, even when it didn't change. This makes the trace table wrong — it obscures which step changed which variable. Only write a value in a cell if that variable changed on that step. Leave other cells blank (or write a dash)
✓ One change per row — write only in the column of the variable that actually changed on that line of code
MISTAKE 4 — Running the loop one too many or too few times
Off-by-one errors in tracing are very common. Students forget to check the loop condition before each iteration, or they assume a WHILE loop always runs at least once. Always re-check the condition at the top of every iteration. If the condition is false from the start, the loop body never runs at all
✓ Check the loop condition before every iteration — stop immediately when it becomes false, even partway through
Summary

Key points — 2.3.2

The purpose of testing is to confirm a program produces correct outputs for valid input, handles invalid input without crashing, and meets its original requirements. Testing finds syntax errors (code that won't run), logic errors (wrong output), and runtime errors (crashes during execution)
Iterative testing — testing at each stage during development. Each module or subroutine is tested as it's built. Final/terminal testing — testing the complete program at the end. Both types are required for a thorough test process
Three types of test data: Normal — valid data the program should accept. Boundary — values at the exact edges of the valid range (a, a−1, b, b+1). Erroneous — invalid data the program should reject (wrong type, far out of range, empty)
A trace table is a dry run of a program — you execute it manually, recording the value of each variable after every step that changes it. Only write a value in the column of the variable that changed. Check the loop condition before each iteration and stop when it's false
All three test data types together make a complete test plan. Normal data proves correctness. Boundary data catches off-by-one errors in validation. Erroneous data proves robustness — that defensive design actually works. Testing with only one type misses most real-world failures
⚡ Next topic: 2.4.1a — Logic Gates. AND, OR, NOT gates and their truth tables.
2.3.2 Complete

Testing
Test Data · Trace Tables · Iterative & Final

Get the full resource pack at CSZone.co.uk

📄
Marked Worksheet
CSZone.co.uk
❓
Quiz
CSZone.co.uk
📊
Slides
CSZone.co.uk
Next Up
2.4.1a — Logic Gates