Test algorithms using trace tables and test data

Algorithm Design, Testing & the Full IGCSE 0478 Syllabus

1. Programme Development Life‑Cycle (PDLC)

The IGCSE specification expects you to know where testing fits into the PDLC. The five stages are:

  1. Analysis – define the problem, list inputs, outputs, constraints and any validation requirements.
  2. Design – decompose the problem, produce structure diagrams, flowcharts and pseudocode.
  3. Implementation (coding) – translate the design into a programming language (or a simulator).
  4. Testing (validation & verification) – use test data, trace tables and error‑handling to confirm the program works correctly.
  5. Documentation & Maintenance – comment code, write user manuals, and update the programme when requirements change.

2. Key Design Concepts

Concept What the syllabus expects Typical classroom activity
Decomposition & Structure diagrams Break a problem into sub‑problems; show the hierarchy of modules. Draw a structure diagram for “Calculate the average of a list of marks”.
Flowcharts Use the standard symbols (terminator, process, decision, input/output, connector) and label each flow line. Produce a flowchart for the “Maximum of three numbers” algorithm.
Pseudocode conventions Line numbers, indentation, clear keywords (READ, IF, THEN, ELSE, END IF, WHILE, FOR, OUTPUT). Write pseudocode for a simple bubble‑sort routine, keeping consistent indentation.
Validation checks Range, type, length, format, check‑digit, consistency – ensure the *right* data is entered. Implement a range‑check for a student’s mark (0 ≤ mark ≤ 100).
Verification checks Visual check, double‑entry, checksum – ensure the data entered is *recorded* correctly. Use double‑entry to verify a list of ID numbers entered by a user.
Trace tables Record the value of every variable after each step, including every loop iteration. Complete a trace table for a factorial routine.

2.1 Flowchart Symbol Reference

SymbolNamePurpose
TerminatorStart / End of the algorithm
ProcessAssignment, calculation or data manipulation
Input/OutputREAD or DISPLAY statements
DecisionIF…THEN…ELSE test (yes/no branch)
ConnectorLink separate parts of a large flowchart

3. Validation vs Verification

3.1 Validation Example in Pseudocode

1. READ mark
2. IF NOT (0 ≤ mark ≤ 100) THEN
3.     OUTPUT "Invalid mark – must be 0‑100"
4.     STOP
5. END IF
6. …   // continue with processing

4. Test Data Categories (Cambridge terminology)

CategoryDefinition (syllabus)Typical purposeExample (max‑of‑three)
Normal Typical values that the algorithm is expected to handle. Confirms basic functionality. a = 5, b = 8, c = 3
Boundary Values at the limits of the allowed range, plus the value just outside the range. Tests range‑check validation. a = 0, b = 0, c = 0 (and a = ‑1, b = 0, c = 0 as “just outside”).
Extreme Very large or very small numbers that may cause overflow/underflow. Relevant for binary/hexadecimal algorithms. a = 9999, b = 10000, c = 9998
Error Invalid or unexpected input – used to test error handling. Triggers validation messages. a = ‑5, b = 2, c = 7 (negative not allowed).

5. Creating a Trace Table

  1. List every variable that can change during execution.
  2. Number each line of the pseudocode (or give a brief description of the operation).
  3. For each test case, add a row for every step, recording:
    • Step number/description
    • Current values of all variables
    • Any output produced at that step
  4. When a loop repeats, create a separate row for each iteration.
  5. Compare the final output with the expected result; if they differ, locate the first row where the values diverge.

5.1 Example – “Maximum of Three Numbers”

Pseudocode (with line numbers and validation)

1. READ a, b, c
2. IF a < 0 OR b < 0 OR c < 0 THEN
3.     OUTPUT "Error – negative numbers not allowed"
4.     STOP
5. END IF
6. SET max ← a
7. IF b > max THEN SET max ← b
8. IF c > max THEN SET max ← c
9. OUTPUT max

Trace Table – Normal case (a = 5, b = 8, c = 3)

Step a b c max Output
1583
2‑5 (validation)583
65835
7 (true)5838
8 (false)5838
958388

Trace Table – Error case (a = ‑5, b = 2, c = 7)

Step a b c max Output
1‑527
2‑5 (validation fails)‑527"Error – negative numbers not allowed"

6. Using Test Data Effectively

  1. Start with normal cases – verify the algorithm works as intended.
  2. Add boundary cases – test the exact limits and the just‑outside values to confirm validation checks.
  3. Introduce extreme cases – check for overflow, underflow, or performance problems (especially for binary/hexadecimal operations).
  4. Finish with error cases – ensure the program detects invalid input and produces a clear error message.
  5. Record results in a trace table for each case; any mismatch should lead to a review of the pseudocode or the validation logic.

7. Common Pitfalls & How to Avoid Them

  • Missing variables – always list every variable that can change; otherwise the error’s location may be hidden.
  • One‑off test data – using only a single set of inputs rarely reveals hidden bugs.
  • Loop rows omitted – each iteration must have its own row; otherwise you cannot see the evolution of variables.
  • Confusing validation with verification – validation checks the *type/range* of data; verification checks that the data entered is *recorded correctly*.
  • Ignoring overflow/underflow – when testing binary or hexadecimal algorithms, include the maximum representable value (e.g. 1111₂ = 15₁₀) and one value beyond it.
  • Incorrect number‑system handling – remember the syllabus expects you to handle negative binary numbers using two’s‑complement and to recognise overflow conditions.

8. Summary Checklist (AO2 – Application of Knowledge)

  1. Have you selected at least one test case from each of the four categories (normal, boundary, extreme, error)?
  2. Is every variable that can change listed in the trace table?
  3. Does each line of the pseudocode (including each loop iteration) have a corresponding row?
  4. Do the final outputs match the expected results for all test cases?
  5. Are validation checks (range, type, etc.) and verification checks (visual, double‑entry) clearly shown in the pseudocode?
  6. Have you noted any failures, identified the offending step, and suggested a correction?

9. Link to Other Syllabus Topics (Paper 2 – Topics 7‑10)

  • Programming concepts – variables, data types, I/O, sequence, selection, iteration, arrays, file handling. (Apply trace‑table technique to array‑based sorting or file‑read/write programmes.)
  • Databases – single‑table design, primary key, basic SQL SELECT/INSERT/UPDATE. (Validate data before inserting; verify with a double‑entry test.)
  • Boolean logic – gate symbols, truth tables, circuit drawing. (A truth‑table is a specialised trace table for logical circuits.)

10. Additional Syllabus Topics (Optional Enrichment)

10.1 Digital Currency & Blockchain (Topic 5.2)

  • Key ideas: decentralised ledger, blocks, hashing, proof‑of‑work.
  • Exam‑relevant fact: a blockchain is immutable because each block contains the hash of the previous block.
  • Example: simple pseudocode that records a transaction and calculates the hash of the previous block.

10.2 Cyber‑Security Threats & Counter‑Measures (Topic 5.3)

  • Threats: malware, phishing, denial‑of‑service, man‑in‑the‑middle.
  • Counter‑measures: firewalls, anti‑virus software, encryption, strong passwords, two‑factor authentication.
  • Key‑point: a firewall filters traffic based on IP addresses and port numbers.

10.3 Robotics & Artificial Intelligence (Topics 6.2‑6.3)

  • Robotics – sensors, actuators, control loops (feedback).
  • AI – simple search algorithms (e.g., depth‑first, breadth‑first) and basic machine‑learning concepts (training data, classification).
  • Exam tip: be able to label a diagram of a robot showing input (sensor), processing (controller) and output (actuator).

10.4 Encryption (Topic 2.3)

  • Symmetric encryption (e.g., Caesar cipher, XOR) and asymmetric encryption (public‑key).
  • Key‑point: a Caesar cipher shifts each letter by a fixed number of positions; decryption shifts in the opposite direction.
  • Example: Pseudocode to encrypt a string using a shift of 3.

10.5 Error‑Detection Methods (Topic 2.2)

  • Parity bit (even/odd), checksum, Cyclic Redundancy Check (CRC).
  • Key‑point: an even‑parity bit makes the total number of 1‑bits in a byte even.
  • Example: calculate a simple 8‑bit checksum by adding all bytes modulo 256.

10.6 Network‑Hardware Details (Topic 3.4)

  • MAC address (48‑bit, hexadecimal), IPv4 (32‑bit dotted decimal) and IPv6 (128‑bit hexadecimal).
  • Key‑point: the subnet mask determines the network and host portions of an IPv4 address.
  • Example: Identify the network address for 192.168.10.45/24.

10.7 Software Interrupts & Firmware (Topics 4.1‑4.2)

  • Interrupts allow hardware or software to pause the CPU and run a special routine.
  • Firmware is low‑level software stored in ROM/Flash that initialises hardware (e.g., BIOS).
  • Exam fact: a software interrupt is invoked by a specific instruction (e.g., INT in x86).

10.8 SQL INSERT & UPDATE (Extended Database Work)

  • INSERT INTO table (col1, col2) VALUES (val1, val2);
  • UPDATE table SET col1 = newVal WHERE condition;
  • Key‑point: after an INSERT you may need to validate that a primary‑key constraint is not violated.

11. Key‑Point Boxes – Exam‑Relevant Facts

12. Further Reading / Practice

  • Cambridge IGCSE Computer Science (0478) – Specification, Section 7: Algorithms.
  • Past paper questions on “trace tables”, “test data” and “validation/verification”.
  • Online simulators (e.g., Python Tutor, Visualgo) that let you step through pseudocode and watch variable values change.
  • BBC Bitesize – IGCSE Computer Science revision pages.

Create an account or Login to take a Quiz

56 views
0 improvement suggestions

Log in to suggest improvements to this note.