What is the difference between verification and validation?

Verification checks that a work product conforms to its specification: “are we building the product right?” Validation checks that the product meets the real needs of its users in its intended environment: “are we building the right product?” A product can pass verification perfectly and still fail validation, because the specification itself was wrong.

Verification

Verification compares an artefact against what it was supposed to be. It applies to everything, not just running code:

• Reviews and inspections of requirements, designs and test cases.
• Code review, static analysis, linters and type checking.
• Unit, integration and system tests that check behaviour against documented requirements or acceptance criteria.

Much verification is static (no code executed), which makes it cheap and early. Finding an ambiguous requirement in a refinement session costs far less than finding it in production.

Validation

Validation compares the product against the user’s intent:

• User acceptance testing (UAT) with real business users.
• Demos and stakeholder reviews of working increments.
• Beta programmes, usability studies, A/B experiments, production analytics and feedback.

Validation needs a working product (or prototype) and real users or their proxies.

An example

The specification for an expense app says: “Receipts must be uploaded as PDF.” The team builds exactly that, and every test passes: verification succeeds. In UAT, sales staff point out they photograph receipts on their phones and have no way to create PDFs while travelling. The product does what it was specified to do, but not what users need: validation fails. The fix is a requirements change (accept images), not a bug fix in the usual sense.

How they relate in practice

In agile teams the line is less formal than in V-model diagrams, but the idea still matters. Acceptance criteria written with examples (for example in Given/When/Then form) are verified by automated tests, while demos at the end of each sprint and product analytics provide continuous validation. Both are needed: verification without validation builds the wrong thing well; validation without verification ships the right idea full of defects.

What interviewers look for

• The two classic phrases, “building the product right” and “building the right product”, with correct mapping.
• Concrete activities for each, including static techniques for verification.
• An example showing that passing one does not imply passing the other.

Common mistakes

• Saying verification is “static” and validation is “dynamic” as the whole definition. Many dynamic tests are verification.
• Mixing up which phrase belongs to which term.