Verification vs Validation

Why it matters

Each question guards against a different risk. Without verification, the product drifts from what was agreed: a rule coded as "greater than" instead of "greater than or equal", a missing error message. Without validation, the team can deliver exactly what was written and still waste the release, because the requirement described the wrong thing.

For a tester, the distinction exposes a trap. Test cases are usually derived from the requirements, so a defect in a requirement is copied into the tests, and those tests still pass. A green test report shows conformance to the specification, not usefulness. Knowing which question each activity answers lets you report precisely what your testing showed and what it did not.

Two questions, two reference points

The ISTQB Foundation syllabus (CTFL v4.0) describes testing as involving both: verification, checking whether the system meets specified requirements, and validation, checking whether it meets users’ and other stakeholders’ needs in its operational environment. The difference is not what you do but what you compare the product with.

• Verification compares a work product with its specification: code with the design, a screen with its acceptance criteria, an API response with the API contract, a requirement with the qualities of a good requirement (clear, consistent, testable).
• Validation compares the product with its intended use: the users’ goals, workflow, devices and data, and the business outcome the feature should deliver. Much of this is never written down, so you have to ask and observe.
• Some teams also say "validation" for input checks (a form that rejects an invalid email) or for schema checks on an API response. Those are behaviours of the software; testing them against the specification is verification.

Both come in static and dynamic forms

Static testing examines a work product without running the software: people review it or tools analyse it. Dynamic testing runs the software. The ISTQB syllabus notes that static testing can be applied for both verification and validation. Dynamic testing serves both too: running tests derived from the requirements is verification, while acceptance testing, which the syllabus describes as focusing on validation, is ideally done by the intended users. So the popular shortcut "verification is reviews, validation is testing" is wrong.

• Static verification: reviewing a story for clear, testable criteria; comparing an API contract with the requirement; static analysis of code.
• Dynamic verification: executing test cases derived from the acceptance criteria.
• Static validation: walking through a story or screen sketches with future users before any code exists.
• Dynamic validation: user acceptance testing, a pilot or beta with real users, usability sessions.

Worked example: booking a clinic appointment

A clinic wants patients to book appointments on its website. The story: "As a patient, I want to book an appointment online, so that I do not have to call the reception." Acceptance criteria: AC1, 15-minute slots from 08:00 to 16:00, Sunday to Thursday; AC2, a patient account can hold at most one future appointment; AC3, a confirmation SMS is sent within 1 minute of booking. Here are four checks on it, in the order they happen: the two static ones in refinement, the two dynamic ones once the feature is built.

• Static verification: in the story review the tester asks whether 16:00 is the last start time or the closing time. The product owner says the last slot starts at 15:45, and AC1 is corrected before any code exists.
• Static validation: reception staff walk through the story and screen sketches. They point out that parents book for their children from one account, so AC2 would stop a parent booking for two children. The limit becomes one future appointment per patient.
• Dynamic verification: tests of the corrected criteria book the 08:00 and 15:45 slots, confirm that no 16:00 slot is offered, check that a second future booking for the same patient is rejected while one for a second child on the same account is accepted, and time the SMS. All pass.
• Dynamic validation: a one-week pilot shows that many patients pick the first free slot without saying what the visit is for, yet a dental cleaning takes two slots. Every criterion was met; the requirement missed a need.

Try it: User Story → Test Scenarios Try it: Requirements → Test Cases

Why you need both

Verification without validation gives software that conforms to a wrong or incomplete specification: no test written from AC1 to AC3 could have failed on the visit-length problem. The ISTQB syllabus lists this trap among its seven testing principles as the absence-of-defects fallacy: testing all the specified requirements and fixing every defect found can still produce a system that does not meet users’ needs, so validation is needed in addition to verification.

Validation without verification is just as risky. Patients trying the main path in a pilot will rarely notice that two people can book the same slot at the same moment, or that a cancelled booking still blocks its slot; such failures need deliberate test data and timing. And legal, security and accessibility rules must be met whether users ask for them or not.

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.