Summary — What This Chapter Covers

1. Validation

Validation is an automated process — meaning the computer does it, not a human — where the program checks whether a piece of input data is sensible and follows the rules the program has set for that field. Think of it like a bouncer at a club door: the bouncer doesn't know if you're really the person on your ID, but they will stop you if your ID is obviously fake, expired, or the wrong shape. That's exactly what validation does — it can't tell if data is true, only whether it's plausible.

For example, if a field asks for someone's age and they type "elephant", validation will catch that instantly, because "elephant" fails a type check (it isn't a number). But if that same person types "25" when their real age is actually 52, validation will happily accept it — 25 is a perfectly sensible, valid age. Validation has no idea it's the wrong number. That's the key limitation to remember for exams.

Range Check

A range check makes sure a numeric value falls between an acceptable minimum and maximum. It's the classic "is this number too high or too low" test.

In Python, the same idea for an age between 0 and 110 (inclusive) uses a while loop that keeps re-asking until the condition is satisfied:

Length Check

A length check counts the number of characters in a string and rejects it if it doesn't match a required length (or minimum length). This is different from a range check — a range check works on numbers as values, a length check works on strings as character counts.

Type Check

A type check confirms the data entered is of the correct data type — for example, that a number field really contains a number rather than text.

Presence Check

A presence check simply confirms that something was typed into a field at all — it stops blank/empty submissions.

Format Check

A format check ensures data follows a specific pattern — this is the most complex of the six because it usually involves pattern matching and string handling (checking individual characters one at a time). A classic example is an ID number that must follow the pattern "XX9999" — two uppercase letters followed by four digits.

Notice the pattern: the algorithm loops through every letter in a list of "valid characters", compares the input character to each one, and sets a flag (ValidChar) to True the moment it finds a match. If it finishes the whole loop without finding a match, the character must be invalid. This "search through a list of valid options" technique comes up constantly in format checks.

A simpler, real-world format check is validating an email address contains both an "@" and a "." — a very rough but common check:

Check Digit

A check digit is a numerical value calculated from the rest of a code (using an algorithm) and then attached onto the end of that code — commonly seen on barcodes and ISBNs (International Standard Book Numbers). When the code is scanned or entered, the computer re-runs the same algorithm on the other digits and compares the result to the check digit. If they don't match, the code was entered or scanned incorrectly.

2. Verification

Verification is the process of checking that data entered into a system is accurate — that it genuinely matches what the person intended to type. This is a completely different job to validation. Validation asks "is this data sensible?" Verification asks "is this data correct?" A mistake here — like registering an account and mistyping your password — can be really frustrating, because you might get locked out of your own account without realising you typed it wrong in the first place.

Double Entry Checking

This involves asking the user to type the same piece of data twice, into two separate input boxes, and then the computer compares the two entries. If they match, the data is accepted. If they don't match, an error message appears and the user tries again. You'll recognise this instantly from every "confirm your password" box you've ever filled in when signing up for a website.

Visual Checks

This involves the user visually looking at the data displayed back on the screen and confirming (usually via a "y/n" prompt or a popup) that it's correct before the program proceeds. If the data is wrong, the user re-enters it.

3. Suitable Test Data

Once a program has validation rules in place, you need to actually test that those rules work correctly — and for that, you can't just throw in random numbers. Good testers deliberately choose data from four categories to make sure every part of the logic is exercised, including the edges where bugs love to hide.

Consider this simple Python program used as the running example for all four categories below — it checks whether someone's age (12–18 inclusive) is accepted:

Normal Data

Data that should be accepted by the program under normal, everyday circumstances — a value clearly within the expected range. Example: entering age 16.

Abnormal Data

Data that is the wrong type entirely and should be rejected — this tests that your validation catches nonsense input, not just out-of-range numbers. Example: entering "F" into the age field.

Extreme Data

The maximum and minimum values of normal data that should still be accepted by the system — these sit right at the very edge of the acceptable range. Example: entering age 12 or 18 (both are the outer limits, but both should still be welcomed).

Boundary Data

Data that sits one step just outside the accepted range on either side — the very next values that should be rejected. This is subtly different from extreme data: extreme data tests the last acceptable value, while boundary data tests the first unacceptable value right next to it. Example: entering age 11 or 19 (one below/above the accepted 12–18 range).

Putting It Together

4. Trace Tables

A trace table is a manual method of testing an algorithm — flowchart, pseudocode, or actual program code — by tracking exactly what happens to every variable, step by step, as the algorithm runs. Think of it as "playing computer" with a pen and paper: you follow the instructions exactly the way a computer would, writing down the value of every variable each time it changes, and noting any output produced.

Trace tables are useful for two main purposes:

• Discovering the purpose of an algorithm — by watching the outputs and intermediate steps unfold, you can work out what an unfamiliar piece of code is actually trying to achieve.
• Recording the state of the algorithm at each step or iteration — this is exactly how you catch logic errors, because a mistake in the algorithm will show up as an unexpected value appearing in the table.

Worked Walkthrough: Finding the Highest Number

Here's a flowchart algorithm that finds the highest of ten user-entered numbers. The first number entered automatically becomes the "highest so far". Then, for each of the next nine numbers, if the new number beats the current highest, it replaces it. Let's trace it with the test data: 4, 3, 7, 1, 8, 3, 6, 9, 12, 10.

Notice the pattern: Highest only gets a new value written in the table when a number actually beats the current highest (3 doesn't beat 4, so Highest stays blank in that row — it hasn't changed). This is the golden rule of trace tables: only write a value in a column when it actually changes. This keeps the table clean and makes it obvious exactly which step caused which update.

What to Memorise

Concepts Checklist

Exam Tips & Common Mistakes