Validation, verification and program testing
Write appropriate checks, choose normal/boundary/erroneous tests, distinguish validation from verification and improve maintainability.
Section 10 · Further programming and testing
Mapped to the Cambridge IGCSE Computer Science 0265 syllabus for exams in 2029. These original explanations and self-checks are independent study support, not Cambridge papers, official marks or grades. Practical programming is taught with worked code and trace tasks; an executable Python workspace and timed digital-exam simulation are not yet available.
Before you begin
- Use the 2029 syllabus for this course. Cambridge specifies Python 3.10 or higher for programming and digital exams for both components. The syllabus currently identifies this route for 2029 only; confirm later-year availability with Cambridge and your school.
Work on paper. Try each question before revealing help, and explain why your method works.
Quick readiness check
Before validation, verification and program testing, which statement is the safest starting point?
What you will learn
- Describe and implement the specified validation checks
- Explain verification and double-entry checks
- Use test data, debug errors and maintain readable code
Validation checks data rules; verification checks accuracy
A range check limits values to a permitted interval; a length check limits characters or digits; a type check checks the kind of value; a presence check requires a value; a format check checks a pattern; a check digit detects some entry errors. Validation checks whether data is reasonable, not whether it is true.
Verification checks that entered or copied data matches the source. A visual check compares by eye; double entry asks for the data twice and compares the entries. A double-entry program accepts the input only when both values match.
Test across normal, boundary and invalid cases
Normal test data represents an ordinary valid case. Boundary data tests the values at and near a limit. Erroneous data should violate one rule, such as a missing value or the wrong type. Good tests target distinct branches and expected outputs.
Syntax errors violate language rules; logic errors give the wrong result; run-time errors occur during execution. Debug by finding the cause and retesting. Meaningful identifiers, appropriate comments, procedures/functions and clear layout make programs easier to maintain.
Pause and explain
Which habit best checks your understanding of validation, verification and program testing?
Worked example
A valid age must be from 13 to 18 inclusive. Give one normal, two boundary and one erroneous test value.
Show the worked solution
- A normal value lies inside the range, such as 16.
- Boundary values include both endpoints 13 and 18.
- An erroneous value lies outside, such as 12.
Answer Normal 16; boundaries 13 and 18; erroneous 12.
Try a topic test
Choose Easy, Normal or Difficult. Save your answers and open worked review after finishing.
Test this topic →From guided practice to a new situation
Write your answer and reasoning first. Use a hint only if you are stuck. The model solution is for self-checking; your written work is not automatically marked.
Write a Python loop that requires a mark from 0 to 100 inclusive, using a range check.
Give me a hint
Repeat while the value is outside the inclusive range.
Compare my reasoning
- Read and convert the value to an integer.
- While mark < 0 or mark > 100, ask again.
- The endpoints 0 and 100 should be accepted.
mark = int(input("Mark: ")) while mark < 0 or mark > 100: mark = int(input("Enter 0 to 100: "))
Look for these in your work
- Range condition
- Inclusive boundary
- Retry loop
A form asks a learner to type an email address twice. Describe the verification and give one issue it does not detect.
Give me a hint
Compare the two entries and distinguish mismatch checking from truth checking.
Compare my reasoning
- The system compares the two strings.
- If they match, the repeated entry is consistent with the first.
- Both entries could still contain the same typo or a fabricated address.
Double-entry verification; it does not prove the address is genuine or correctly copied from a source.
Look for these in your work
- Method described
- Comparison stated
- Limit identified
Design normal, boundary and erroneous tests for a username that must be 4–12 characters and contain no spaces.
Give me a hint
Test shortest/longest accepted values and one just outside each limit plus a format violation.
Compare my reasoning
- Normal: 'study8' (valid length, no space).
- Boundary: a 4-character and a 12-character name; erroneous: 3 or 13 characters.
- Erroneous format: a six-character name containing a space, such as 'ab cd'.
Normal 'study8'; boundaries length 4 and 12; invalid lengths 3/13 and a space-containing value.
Look for these in your work
- Valid normal data
- Both length boundaries
- Invalid length and format
Common mistakes
- Treating validation as proof that a value is true.
- Testing only typical values and missing boundaries.
- Using a global variable when a local result would be clearer.
What can you explain now?
Does a presence check prove that an entered email address is genuine?
Compare with the explanation
No
It only checks that a value was supplied, not that it is authentic or correct.
After trying it yourself, choose your next review. This is your self-assessment.
Your review choice appears on Today. Sign in to sync it across devices.
Make it stick
How do validation, verification, testing and maintainable code address different kinds of programming risk?
If you needed the solution, close it and solve the problem again from a blank page. A correct answer is stronger when you can explain the reason for each step.