03 Validation, verification, check digits and testing

Validation, verification, check digits and testing

← Index · Solutions

Priority key · Priorities guide emphasis; they do not remove taught scope.

Exam recall

Validation checks rules; verification checks faithful entry. For a check digit, follow weights, direction, modulus and special cases exactly.

Validation versus verification priority/high

Imagine the true mark is 72 but you type 27. A range check 0–100 accepts 27 because it is allowable. Comparing the entry against the original 72 can detect the copying error. This is the central distinction: validation checks a rule; verification checks faithful entry against a source or repeated entry.

Validation checks whether input satisfies specified rules for acceptable data. A valid age can still be factually wrong. Verification checks that data was copied or entered as intended, such as double entry compared by software or a visual comparison with the original source. Neither guarantees that the original source was correct.

Validation check	Example	Limitation
Presence	A required name is not empty	Does not prove it is a real name.
Existence	A selected CourseID exists in the course table	Does not prove the user selected the intended course.
Type	Quantity can be interpreted as an integer	Integer −5 might still be unacceptable.
Range	0 ≤ mark ≤ 100	70 passes even if the true mark is 71.
Length	An identifier contains exactly six characters	Length alone does not check allowed characters.
Format	Four digits followed by a letter	A correctly formatted value might be unassigned.
Check digit	Recomputed digit matches the appended one	Some errors can remain undetected.

Explain the rule applied to the field, not merely “range check”. A telephone number is usually stored as text: leading zeroes and + are meaningful, and arithmetic on it is not the purpose.

Check digits priority/high

flowchart LR
    A[Original data digits] --> B[Apply weights and modulus]
    B --> C[Append check character]
    C --> D[Entered identifier]
    D --> E[Recalculate from entered data digits]
    E --> F[Compare with entered check character]

A matching result means the check did not detect an error. It is not an independent source of the true data: the check character is calculated from the digits themselves.

A check digit is derived from other digits and appended to help detect entry/transmission errors. Common errors include replacing a digit and swapping adjacent digits. Detection depends on the algorithm; never claim every error is caught.

Follow the question’s algorithm exactly: digit order, weights, modulus, complement and special symbols can all differ. For a weighted mod-11 rule with five digits, weights 6,5,4,3,2 from left to right, compute the weighted sum and remainder. In the convention used here: remainder 0 → 0; remainder 1 → X; otherwise check character is 11−remainder.

Testing and debugging priority/medium

Normal data represents typical accepted input. Boundary data lies on or immediately around a limit. Invalid/erroneous data violates the requirements. Extreme valid values are the minimum/maximum allowed. Always pair a test input with an expected result and purpose.

For allowed integer marks 0–100, use 0 and 100 (accepted endpoints), −1 and 101 (rejected neighbours), 56 (normal), and "abc" (invalid type). When asked for a particular category, choose a test that clearly demonstrates it.

Syntax errors violate language grammar; runtime errors occur during execution; logic errors run but produce incorrect behaviour. Trace tables and small known cases expose logic errors. A test passing is evidence for that case, not proof of correctness for all inputs.

Worked example — original using HCI 2025 Q4’s rule

Data digits 12345: weighted sum = 1×6+2×5+3×4+4×3+5×2 = 50. Remainder = 50 mod 11 = 6. Check character = 11−6 = 5. Full identifier: 123455. The first five characters are data and the last is the check character, even when both happen to be 5.

Code: distinguish format failure from check failure priority/high

def validate_identifier(code):
    digits = "0123456789"
    if len(code) != 6:  # Establish safe positions before indexing the string.
        return "invalid format"
    if any(character not in digits for character in code[:5]):  # Check before int().
        return "invalid format"
    if code[5] not in digits + "X":
        return "invalid format"
    total = 0
    for index in range(5):
        total += int(code[index]) * (6 - index)  # Left-to-right weights: 6,5,4,3,2.
    remainder = total % 11
    if remainder == 0:
        expected = "0"
    elif remainder == 1:
        expected = "X"
    else:
        expected = str(11 - remainder)
    if code[5] != expected:  # Valid format can still contain a wrong check digit.
        return "incorrect check digit"
    return "valid"

The length check happens before indexing; digit checks happen before conversion. any(...) means at least one generated condition is true; an explicit loop can replace it if required. This function assumes its argument is a string. Alternatively, for ordinary numeric input, catch the specific ValueError raised by int(text) before applying range checks. A broad except can hide unrelated programming errors.

Practice

Exam focus: validation/verification recur in HCI 2022 modified Q2, 2023 Q2 and 2024 Q3. HCI 2025 Q4 combines error types, string representation and a check-digit algorithm. Use the original Q4, PDF p.3 to practise interpreting an algorithm supplied in prose; its requested function contract takes precedence over this chapter’s teaching interface.

Answering approach: state the field, exact rule and purpose. For code, separate format validation from the calculation, then implement every special mapping. For tests, write input → expected result → reason for choosing it.

03A — original. A form accepts an integer quantity from 1 to 20 inclusive. Supply one normal test, the two valid endpoints and the two adjacent invalid values, with expected outcomes. Explain how double entry differs from range validation.

03B — adapted from HCI 2025 Q4. Using the mod-11 rule above, calculate the full identifier for 10003. Explain why text is suitable for the full identifier and give one limitation of check-digit validation.

Hints

03B: the weighted sum is 12. Check the special case before calculating a numeric character.

Revision checklist

• 03.1 Distinguish validation from verification and explain what neither guarantees.
• 03.2 Choose and justify existence, format, length, presence, range and type checks.
• 03.3 Calculate and validate a check digit using the exact weights, direction, modulus and mapping supplied.
• 03.4 Handle the modulus-11 special cases and preserve identifiers with leading zeroes or letters.
• 03.5 Write code that distinguishes invalid format from an incorrect check digit.
• 03.6 Explain detectable error types without claiming every error is detectable.
• 03.7 Identify and correct syntax, runtime and logic errors.
• 03.8 Design normal, boundary and erroneous test cases with expected outcomes.
• 03.9 Use appropriate exception handling and distinguish checking before conversion from handling a failed conversion.
• 03.10 Construct a trace table recording changing variables, conditions, outputs and return values.

Visual revision mindmap

Open this mindmap and its text version · All 21 mindmaps

Your mindmap framework

Centre: Validation, verification, check digits and testing. Build the six branches below. For each subbranch, add a short definition, a labelled sample and one exam trap from memory; then check the chapter.

flowchart LR
    C["03 • Revision map"]
    C --> B0["Validation versus verification"]
    C --> B1["Choose a validation check"]
    C --> B2["Check-digit calculation"]
    C --> B3["Validation algorithm"]
    C --> B4["Testing and debugging"]
    C --> B5["Visual checks and mistakes"]

• Validation versus verification

  • Validation: specified acceptable-data rules.
  • Verification: faithful copying or repeated entry.
  • Both can accept data from an incorrect original source.
  • Draw true 72 → typed 27 → range check passes.

• Choose a validation check

  • Presence versus existence.
  • Type versus range.
  • Length versus format.
  • State field → exact rule → reason; preserve textual identifiers.

• Check-digit calculation

  • Identify data digits and check character.
  • Order, weights, weighted sum, modulus.
  • Complement and special mappings: 0 or X where specified.
  • Append or compare; follow the question’s exact scheme.

• Validation algorithm

  • Establish length before indexing.
  • Check characters before numeric conversion.
  • Calculate expected check character.
  • Distinguish invalid format from incorrect check digit.

• Testing and debugging

  • Normal, boundary, erroneous inputs.
  • Input → expected outcome → test purpose.
  • Syntax versus runtime versus logic errors.
  • Trace variables and conditions; handle expected exceptions.

• Visual checks and mistakes

  • Draw calculation pipeline with one worked identifier.
  • Make a test table for both endpoints and neighbours.
  • Include leading zeroes, X, wrong length and wrong checksum.
  • Avoid: check digit corrects errors or detects every error.

Close the notes and test the map: explain one branch aloud, sketch its sample, then answer a linked practice question. Mark any missing link to revisit.

Source trail

9569 §§1.5.1–1.5.6; school Introduction and Check Digit PDFs.

HCI 2022 Q2; 2023 Q2(a); 2024 Q3(a–b); 2025 Q4, Q5(e).

Source guide records provenance and original-paper locations.