[7.5 a & b] Validation & verification
[7.5 a & b] Validation & verification: making input data reliable
When people type data into a computer system, errors can slip in easily: a mistyped digit, a missing field, or a value in the wrong format. To reduce these mistakes, systems apply validation and verification. Validation is a set of automated checks that test whether input is reasonable and acceptable before it is processed. Verification is about confirming that data captured matches the original source, helping to spot transcription errors. For IGCSE, you should be able to explain and choose appropriate validation checks such as range, length, type, presence, format, and check digit, and verification methods such as visual checking and double entry.
Validation vs verification
Validation does not guarantee that data is correct, only that it meets rules. For example, a date of birth of 31/02/2010 fails a format-aware date rule, but a date like 01/01/1900 might still be valid yet unrealistic for a school pupil. Verification attempts to ensure that the data entered matches its source (e.g. a paper form), catching typing mistakes. Effective systems frequently use both: validation rules to block implausible inputs, and verification steps to ensure accurate transcription.
Core validation checks and where to use them
| Validation type | What it checks | Typical examples | Strengths | Limitations |
|---|---|---|---|---|
| Range | Value falls between minimum and maximum boundaries | Exam mark 0–100, age 5–18 for a school system | Blocks out-of-range values quickly | Still accepts the wrong value if it is within the range (e.g. 11 instead of 10) |
| Length | Input length equals (or lies within) specified limits | UK postcode segments, fixed-length student ID, password minimum length | Prevents too-short/too-long entries | Correct length is not the same as correct content |
| Type | Data is of the expected data type | Quantity must be INTEGER; price must be REAL | Stops letters in numeric-only fields | Cannot detect a wrong number of the right type |
| Presence | Field is not left blank | Required fields: surname, email, consent box | Ensures essential data is provided | Does not ensure the value provided makes sense |
| Format | Pattern matches a rule (often a regular format) | Dates as DD/MM/YYYY, emails contain @ and domain | Quickly rejects obvious misformats | Patterns can be over- or under-strict; may allow realistic-looking but invalid data |
| Check digit | Mathematical test on digits detects common typing errors | ISBNs, some account numbers, barcodes | Detects transpositions and single-digit mistakes | Does not guarantee that the number refers to a real record |
Range check: boundaries, inclusivity, and common pitfalls
Range checks compare an input against a defined minimum and maximum. Decide whether your boundaries are inclusive (≤ and ≥) or exclusive (< and >). Be clear whether the units are correct (e.g. kilograms vs grams) and whether the range is sensible for the context.
A school mark out of 100 accepts 0 and 100 as valid. This reduces frustration when a pupil legitimately scores full marks or none, while still blocking values like -1 or 105.
For a competition accepting ages strictly between 12 and 16, an input of 12 or 16 should be rejected. Exclusive boundaries enforce narrow eligibility rules.
Entering height as 170 when the system expects metres would be out of range if the valid range is 1.0–2.5. Clear labels and examples help users supply values in the correct units.
Length check: fixed vs variable constraints
Length checks confirm that an input has the correct number of characters. They are frequently combined with format rules to ensure both size and structure are sensible.
A student number must be exactly 8 characters. Entries with 7 or 9 characters are rejected immediately.
Password policies often require at least 8 characters, but also cap maximum length to protect legacy systems. Combine with other checks such as character variety.
Users can accidentally add a space at the end. Good validation trims whitespace before applying the length rule so genuine values are not rejected unfairly.
Type check: enforcing data types
Type checks ensure the data supplied is of the expected data type (INTEGER, REAL, STRING, BOOLEAN). They prevent obviously incorrect entries, like letters in a numeric field, but cannot spot a wrong number of the right type (e.g. 21 instead of 12).
Quantities and ages usually require whole numbers. Reject inputs containing letters or mixed symbols unless explicitly allowed (e.g. 12.5 for weight as REAL).
Consent fields should be restricted to true/false (or Yes/No). Radio buttons or tick boxes reduce errors compared with free text input.
Some systems auto-convert strings like "0012" to numbers, losing leading zeros that might be meaningful for IDs. Protect identifiers by keeping them as strings.
Presence check: required fields
A presence check ensures essential fields are not left blank. Combine presence with other checks so that a non-empty value also has the correct format or range. For example, an email field should be present and match a suitable pattern.
Format check: patterns and real-world structure
Format checks test whether the input matches a pattern. These rules should be specific enough to catch mistakes, but not so strict that valid real-world cases are rejected. For dates, consider leap years; for postcodes, allow valid space placement and letter-number combinations.
Check day, month, and year positions, then apply calendar rules such as 30-day months and leap years. Rejecting 31/04/2012 improves data quality.
Require one @ symbol with characters either side and a sensible domain. Advanced validation may also check for valid top-level domains.
Allow upper case letters, the correct letter–number patterns, and a single space before the final three characters (e.g. AB1 2CD). Trim and normalise case on input.
Check digits: why they work
A check digit is computed from the other digits in a number using a rule. When the number is typed later, the system recalculates the check digit and compares it with the typed one. If they do not match, a likely typing error has occurred. Different systems use different algorithms (e.g. weighted sums, modulus operations). These detect common mistakes like swapping two neighbouring digits or pressing an adjacent key.
If a user types 123456 instead of 123457, the recalculated check digit will usually differ, flagging the error. This helps catch slips quickly.
Swapping two adjacent digits (e.g. 132456 instead of 123456) often changes the weighted sum, causing a mismatch and an error message.
A correct check digit does not prove that the number refers to a real customer or account. It only shows the number passes the mathematical test.
Verification: matching input to its source
Verification helps ensure that the captured data is the same as the original. It focuses on detecting typing and reading mistakes rather than judging whether the data is reasonable.
| Method | How it works | Where used | Strengths | Limitations |
|---|---|---|---|---|
| Visual check | The person who entered data reads it back and compares with the source | Quick checks on paper-to-screen entry | Low cost and immediate | Human attention varies; mistakes can be missed |
| Double entry | Two independent entries are made; the system compares for exact match | Critical fields like passwords or email addresses | Very effective at spotting typing errors | Time-consuming; if both people make the same mistake, it still passes |
Choosing the right checks
Good design selects the lightest set of checks that meaningfully reduce risk. Combine presence, type, and format for structured fields like email; use range for numeric limits; add a check digit for identifiers where transcription is common. For sensitive workflows (e.g. creating a new account), add verification: show users a summary to review (visual check) or ask them to confirm the value twice (double entry).
Deep Dive: Layering rules to prevent bad data
Layering small, precise rules is usually better than one over-strict rule. For example, for a pupil's date of birth, use: presence (must not be blank), format (DD/MM/YYYY), calendar validity (e.g. 29/02 only on leap years), and range (reasonable ages for the school). Each rule contributes a different type of protection, and friendly error messages help users correct issues quickly.
Key terminology
- Validation: automated checks that test whether input meets predefined rules.
- Verification: processes that ensure captured data matches its original source.
- Presence check: prevents required fields from being left blank.
- Type check: confirms data is of the expected data type (e.g. INTEGER, REAL, STRING).
- Format check: tests input against a pattern or structure (e.g. date formats).
- Range check: ensures a numeric value falls within specified limits.
- Check digit: a digit computed from the others to detect typing errors.
- Double entry: entering the same data twice and comparing for an exact match.
Key Takeaways
- Validation tests reasonableness (range, length, type, presence, format, check digit); it does not prove correctness.
- Verification checks accuracy of entry (visual checks and double entry), helping to catch transcription errors.
- Combine small, targeted validation rules with clear error messages to guide users to correct inputs.
- Check digits mathematically detect common digit errors but do not confirm that a record actually exists.
- Choose checks appropriate to the field: e.g. presence+format for emails, range for marks, type for quantities.
- Layering validation with verification produces cleaner datasets and fewer downstream problems.