Verification vs Validation
These two words get confused constantly, partly because they sound so similar. But they ask two genuinely different questions, and a team that only does one of them ships broken software — either software that's well-built but solves the wrong problem, or software that solves the right problem but is full of defects.
Verification asks: "Are we building the product right?" — is each artifact (a design doc, a piece of code) correct and internally consistent, without necessarily running the software.
Validation asks: "Are we building the right product?" — does the finished, running software actually do what the user needs, checked by executing it.
Verification: Reviews, Walkthroughs, Inspections
Verification is largely static — it happens without executing the software. It checks documents, designs, and code against specifications and standards, usually by having people look at them carefully.
| Technique | What it is |
|---|---|
| Review | A structured or informal check of a document (requirements, design) by peers or stakeholders, looking for errors or gaps |
| Walkthrough | The author of a document talks a group through it step by step, inviting feedback as they go |
| Inspection | A formal, rigorous, checklist-driven examination, often with a dedicated moderator, aimed at finding defects in a document with minimal ambiguity about what counts as a defect |
RecipeBox Example: Verification
Before a single line of code is written for the "Add Recipe" screen, the team holds a design review of the screen's spec document. A reviewer notices the spec lists fields title, ingredients, steps, photoUri, category but never mentions prepMinutes at all — even though the database schema the developers already agreed on includes it. That's a verification catch: an inconsistency found by inspecting a document, without running any software, because nothing has been built yet.
Validation: Actual Testing
Validation is dynamic — it requires the software (or at least a working piece of it) to exist and be executed. It checks the real, running product against actual requirements and real usage.
RecipeBox Example: Validation
Weeks later, the "Add Recipe" screen is built. A tester opens the real app, fills in a title, ingredients, and steps, but leaves prepMinutes blank, and taps Save. The screen accepts it silently instead of showing a validation error as the (by-then corrected) spec requires. That's a validation catch: a defect found by actually running the built software against its requirement.
| Verification | Validation | |
|---|---|---|
| Question | Are we building the product right? | Are we building the right product? |
| Type | Static (no code execution) | Dynamic (executes the software) |
| Checks against | Specifications, standards, design docs | User needs, actual requirements, real behavior |
| Typical activities | Reviews, walkthroughs, inspections, audits | Unit, integration, system, and acceptance testing |
| When it happens | Throughout development, often before code exists | Once a working build exists |
| Who's usually involved | Analysts, designers, developers, sometimes testers | Testers, end users, developers |