This module is about trusting a program. Validation stops unacceptable data from going in, verification checks that the data entered matches what was meant, and testing shows whether the program does what the requirement says. Questions reward exact vocabulary and careful, step-by-step working.
For the exact scope and current codes, read the Cambridge IGCSE Computer Science syllabus page for your exam year. This module belongs to the wider Computer Science learning guide.
What should I already know?
You should be able to read a short algorithm with IF, loops and variables. If tracing is new to you, look at hardware and processing and software and systems for context, and at data transmission and checking for the idea of checking data.
Orienting example: one rule, three jobs
A fictional club says: “Age must be a whole number from 13 to 17.”
First, validation enforces the rule. A range check rejects 20 and 12, and a type check rejects “abc”.
Second, testing asks whether the check is written correctly. Test data 13, 17, 12 and 18 shows whether the comparisons use >= and <=.
Third, verification asks whether the age typed is the age on the form. A range check accepts 16 when the real age is 15, but double entry would catch it.
Each job catches a different kind of fault. That is the reason all three appear together.
What order should I study the lessons in?
- Choose a validation rule from a requirement: the five checks and the key words that identify them.
- Distinguish verification from validation: double entry, visual check and why valid data can still be wrong.
- Design normal, boundary and invalid test data: test tables with expected results.
- Explain an expected result before running code: tracing with a table to predict the output.
- Identify an untested branch: checking that every route through the code has a test.
Follow this order. Each lesson uses the one before it, and the last one asks you to apply all of them.
What are the common traps?
- Saying validation “makes sure the data is correct”. It makes sure the data is reasonable.
- Choosing only normal test data and forgetting both sides of each boundary.
- Reading
>=as>when predicting output. - Treating passing tests as proof that all of the code ran.
How do I use the practice set?
Work through the mixed practice set on paper, then compare with the worked answers. The restricted pseudocode trace trainer and the safe Python reasoning sandbox let you step through loops and conditions, and the mistake log and retest queue helps you track repeat errors. If you want a teacher to look at your own working, see online one-to-one Computer Science tuition.