Best practices: strong passwords, regular updates, backups, least‑privilege principle.
2. Programme‑Development Life‑Cycle (PDLC) and Testing
The Cambridge IGCSE 0478 syllabus defines the PDLC as:
Analysis – understand the problem, list inputs, outputs and constraints.
Design – decompose the solution, produce structure diagrams and flowcharts.
Implementation (Coding) – write pseudocode or a program.
Testing (Verification & Validation) – run the algorithm with carefully chosen test data.
Evaluation & Maintenance – refine, optimise or extend the solution.
Testing is the fourth stage; it checks that the algorithm does exactly what the specification demands (verification) and that it behaves correctly for all permitted inputs (validation).
3. Decomposition, Structure Diagrams & Flowcharts
Before selecting test data, the solution must be broken into logical parts (decomposition). Two visual tools are used in the exam:
3.1 Structure Diagram
Shows the hierarchy of modules/procedures.
Each box represents a sub‑task; arrows indicate the flow of control.
3.2 Flowchart (Cambridge symbols)
Symbol
Name
Purpose
Oval
Start / End
Marks the entry and exit points.
Parallelogram
Input / Output
Read data or display results.
Rectangle
Processing
Assignments, calculations, calls.
Diamond
Decision
IF / selection – true/false branches.
Arrows
Flow of control
Shows the direction of execution.
4. Why Test Data Is Important
Good test data demonstrates that an algorithm:
Produces the correct output for typical inputs (normal cases).
Negative numbers where only positives are allowed, non‑numeric characters in a numeric field, out‑of‑range indices.
6. Step‑by‑Step Process for Selecting Test Data
Read the algorithm specification carefully.
Identify the input domain (type, range, constraints).
List normal cases that represent typical usage.
Determine the boundary values for each input variable.
Create error cases that violate each constraint.
Arrange the test data in a table and record the expected output.
Run the algorithm, fill a trace table, and compare actual results with expectations.
7. Worked Example 1 – “Maximum Value in a List”
7.1 Pseudocode
INPUT: list L of n integers (n ≥ 1)
max ← L[1]
FOR i ← 2 TO n DO
IF L[i] > max THEN
max ← L[i]
END IF
END FOR
OUTPUT: max
7.2 Structure Diagram
MaximumInList
│
├─ Read list L
├─ Initialise max ← L[1]
├─ Loop i = 2 … n
│ └─ Compare L[i] with max
│ └─ Update max if larger
└─ Output max
7.3 Flowchart (Cambridge symbols)
Maximum‑in‑List flowchart (textual description)
Oval – Start
Parallelogram – INPUT L
Rectangle – max ← L[1]
Diamond – i ≤ n ? (loop control)
Diamond – L[i] > max ?
Rectangle – max ← L[i] (if true)
Arrow back to loop‑control after incrementing i
Parallelogram – OUTPUT max
Oval – End
7.4 Trace‑Table Worksheet
Step
i
L[i]
max (before)
max (after)
7.5 Test‑Data Table
Test #
Input List L
Category
Expected Output (max)
Notes
1
{3, 7, 2, 5}
Normal
7
Typical mixed values.
2
{10}
Boundary – minimum size
10
Single‑element list.
3
{-4, -1, -9}
Boundary – all negative
-1
Algorithm works with negatives.
4
{0, 0, 0}
Boundary – all equal
0
max should never change.
5
{}
Error – empty list
“Error: list must contain at least one element”
Violates pre‑condition n ≥ 1.
6
{5, “a”, 9}
Error – non‑numeric element
“Error: all elements must be integers”
Tests type checking.
7
{2³¹‑1, -2³¹}
Boundary – integer limits
2³¹‑1
Ensures no overflow occurs.
7.6 Applying the Test Data
Enter the input list into the program.
Run the algorithm and fill the trace‑table with the values of i, L[i] and max at each iteration.
Compare the final max (or error message) with the “Expected Output” column.
Record any discrepancy and decide whether it is a flaw in the algorithm or an inadequate test case.
8. Debug the Algorithm (AO3)
The following version contains a subtle error. Identify the problem and rewrite the corrected line.
INPUT: list L of n integers (n ≥ 1)
max ← L[1]
FOR i ← 1 TO n DO // ← error: loop starts at 1
IF L[i] > max THEN
max ← L[i]
END IF
END FOR
OUTPUT: max
Explanation: The loop should start at i = 2 because max is already initialised with L[1]. Starting at 1 makes the first comparison redundant and, if the list were empty, would cause an out‑of‑range error.
Corrected line:
FOR i ← 2 TO n DO
9. Worked Example 2 – “Average of a List of Positive Integers”
9.1 Pseudocode (uses an array, a loop, and the ROUND library routine)
PROCEDURE averagePositiveIntegers()
INPUT: n (number of values, n ≥ 1)
DECLARE integer L[1..n]
FOR i ← 1 TO n DO
INPUT: L[i]
IF L[i] < 0 THEN
OUTPUT: “Error: only positive integers allowed”
STOP
END IF
END FOR
sum ← 0
FOR i ← 1 TO n DO
sum ← sum + L[i]
END FOR
avg ← sum / n
avgRounded ← ROUND(avg, 2) // round to 2 decimal places
OUTPUT: “Average = ” & avgRounded
END PROCEDURE
9.2 Test‑Data Table (minimum five rows)
Test #
n
List L
Category
Expected Output
1
4
{5, 10, 15, 20}
Normal
Average = 12.50
2
1
{8}
Boundary – minimum size
Average = 8.00
3
3
{0, 0, 0}
Boundary – zero values (still valid)
Average = 0.00
4
5
{12, -3, 7, 9, 4}
Error – negative number
“Error: only positive integers allowed”
5
0
{}
Error – n outside allowed range
“Error: list must contain at least one element”
10. Key Programming Constructs (Side‑Box)
Arrays DECLARE integer L[1..n] – creates a one‑dimensional array with indices 1 to n.
Procedures PROCEDURE name(parameters) … END PROCEDURE – encapsulates reusable code.
Library Routines (selected)
ROUND(x, d) – rounds x to d decimal places.
RANDOM(a, b) – returns a random integer between a and b inclusive.
LCASE(s), UCASE(s) – convert a string to lower/upper case.
LEN(s) – length of a string.
ABS(x) – absolute value.
11. Guidelines for Good Test Data
Cover every input variable at least once.
Include at least one case from each category (normal, boundary, error).
For loops, test: zero iterations (if allowed), one iteration, and many iterations.
Document expected results clearly; they become the reference when checking the trace table.
Keep the number of test cases manageable – quality over quantity.
When possible, combine two concepts in one case (e.g., boundary value that also triggers an error).
12. Common Pitfalls
Assuming the algorithm works because it passes only normal cases.
Neglecting the smallest and largest permissible inputs.
Forgetting to test invalid input that should trigger error handling.
Using test data that does not exercise all branches of a decision structure.
Skipping the trace‑table step – without it, hidden logic errors are easy to miss.
Hard‑coding expected results without calculating them independently.
13. Practice Exercise (Extended)
Write pseudocode for a procedure countVowels that receives a text string and returns the number of vowel characters (a, e, i, o, u – case‑insensitive). Then:
Create a structure diagram and a flowchart for the procedure.
Produce a test‑data table with at least three normal cases, two boundary cases and two error cases.
For each normal/boundary case, fill in a trace table showing the values of the loop index, current character, and running total.
13.1 Sample Pseudocode
PROCEDURE countVowels()
INPUT: text (string)
DECLARE integer count ← 0
DECLARE integer i ← 1
WHILE i ≤ LEN(text) DO
ch ← LCASE( text[i] ) // convert to lower case
IF ch = 'a' OR ch = 'e' OR ch = 'i' OR ch = 'o' OR ch = 'u' THEN
count ← count + 1
END IF
i ← i + 1
END WHILE
OUTPUT: count
END PROCEDURE
13.2 Test‑Data Table
Test #
Input text
Category
Expected Output (count)
Notes
1
“Computer Science”
Normal
5
Mixed case, spaces ignored.
2
“AEIOUaeiou”
Normal – all vowels
10
Tests case‑insensitivity.
3
“bcdfg”
Normal – no vowels
0
Ensures count stays zero.
4
“” (empty string)
Boundary – length 0
0
Loop should not execute.
5
“a”
Boundary – single character
1
One‑iteration loop.
6
12345
Error – non‑alphabetic characters
0
Digits are ignored (not vowels).
7
NULL (no input)
Error – missing input
“Error: no string supplied”
Depends on programme’s input validation.
13.3 Sample Trace Table (Test 1)
i
ch = LCASE(text[i])
Is vowel?
count (after)
14. Summary & Exam Tips
Memorise the five stages of the PDLC; the exam often asks you to label them.
Practice drawing structure diagrams and flowcharts using the exact Cambridge symbols – marks are awarded for correct notation.
When creating test data, always list at least one case from each of the three categories.
Trace tables must show every variable that changes; missing a column can lose marks.
Read the specification carefully: pay attention to pre‑conditions (e.g., “n ≥ 1”) – they guide your boundary and error cases.
For debugging questions, look for off‑by‑one errors, incorrect loop limits, missing initialisation, and misplaced END statements.
Use the “Key Programming Constructs” box as a quick reference for library routines and array syntax.
Your generous donation helps us continue providing free Cambridge IGCSE & A-Level resources,
past papers, syllabus notes, revision questions, and high-quality online tutoring to students across Kenya.