QLDDigital SolutionsSyllabus dot point

How does a digital solution check that the data entered into it is correct and trustworthy?

Design and implement data validation that checks input for type, range, presence and format so that only valid data enters the solution, protecting data integrity

A focused answer to the QCE Digital Solutions Unit 3 dot point on validation. The difference between validation and verification, the standard checks (type, range, presence, format, lookup), where validation sits between interface and database, and how it protects data integrity.

Generated by Claude Opus 4.76 min answerUpdated 2026-05-29

Reviewed by: AI editorial process; not yet individually human-reviewed

Have a quick question? Jump to the Q&A page

Jump to a section

What this dot point is asking
Validation versus verification
The standard validation checks
Where validation sits
Validation and the user experience
Integrity beyond input

What this dot point is asking

QCAA wants you to make sure only correct, usable data enters your solution. Validation is the automatic checking of input before it is stored or processed, and it is what protects data integrity (the accuracy, completeness and consistency of stored data). A solution that stores a mark of 250 out of 100, or an empty email field, has a data-integrity failure that every later report and query inherits. Validation is assessed in IA2 implementation and tested in your test plan.

Validation versus verification

These are different ideas and markers reward the distinction.

Validation checks that data is reasonable against rules: is it the right type, in range, present and correctly formatted? It cannot prove the value is true, only that it is plausible.
Verification checks that data was entered correctly, for example a double-entry password field or a confirmation prompt.

A birth year of 1850 passes verification if it was typed accurately, but fails validation because it is out of a sensible range.

The standard validation checks

QCAA expects you to know and apply these checks:

Type check: the value is the expected data type (a number where a number is required).
Range check: a numeric value falls between a minimum and maximum (a mark from 0 to 100).
Presence (existence) check: a required field is not empty.
Length check: a string is within an allowed number of characters (a 4-digit PIN).
Format (pattern) check: the value matches a pattern, often a regular expression (an email, a postcode).
Lookup check: the value exists in a known set (a subject code that is in the subjects table).

Validating an enrolment mark in Python

def validate_mark(raw):
    if raw.strip() == "":                 # presence check
        return False, "Mark is required"
    if not raw.isdigit():                 # type check
        return False, "Mark must be a whole number"
    mark = int(raw)
    if mark < 0 or mark > 100:            # range check
        return False, "Mark must be 0 to 100"
    return True, mark

ok, result = validate_mark("250")
print(ok, result)                         # False  Mark must be 0 to 100

The function applies presence, type and range checks in order and returns a clear message, so the interface can tell the user exactly what to fix. Returning the converted integer on success means the caller never re-parses the input.

Where validation sits

Validation belongs between the user interface and the database. The interface collects raw text; the program validates it; only valid, typed data reaches the database. Putting validation only in the interface is fragile because data can arrive from imports or APIs too, so the safest designs validate in the program layer and also use database constraints (NOT NULL, CHECK, foreign keys) as a second line of defence. This layering is what keeps integrity intact even when one path is bypassed.

Validation and the user experience

Good validation is also a usability feature. Inline messages that name the field and the rule, sensible defaults, and input masks that prevent bad data being typed at all reduce user frustration. This connects validation to the user-centred interface design dot point: the goal is not just rejecting bad data but guiding the user to enter good data the first time.

Integrity beyond input

Data integrity is broader than input validation. It also depends on referential integrity in the database (foreign keys that prevent orphaned rows), transactions that keep related updates consistent, and constraints that stop duplicate keys. Input validation is the front line, but a strong solution defends integrity at every layer where data is written.