The one-sentence difference between verification and validation
Verification is the act of confirming that a work product — a requirement, a design, a test plan, a piece of code, a release note — matches the specification it is supposed to satisfy.
Validation is the act of confirming that the product, once built, satisfies the real need of the people who will use it, in the environment where they will use it.
That is the whole distinction, and it survives translation into any team's vocabulary. Verification asks did we build what we said we would build. Validation asks whether what we said we would build was the right thing. One question is answered by reading and comparing. The other is answered by using.
Teams often say they need to validate and verify a release, as though those were two names for one activity. They are not. The two consume different evidence and they fail in different ways. A specification that was wrong from the start can pass verification perfectly and fail validation completely. A product that delights its first real users can still carry internal inconsistencies that verification would have found for the price of an afternoon.
Verification and validation side by side
The quickest way to keep them apart is to compare what each one is measured against.
| Verification | Validation |
|---|---|---|
Question it answers | Did we build the product right, against the specification? | Did we build the right product, for the need? |
Measured against | Requirements, design documents, acceptance criteria, agreed standards | Real user needs, business goals, the live environment |
When it runs | Throughout — requirement review, design review, code review, test review, build checks | Later and repeatedly — integration, system, acceptance, beta, after release |
Typical evidence | Review notes, traceability entries, unit and integration results, spec-to-build comparisons | Observed sessions in a real flow, acceptance sign-off, support tickets, task completion |
Who usually drives it | Developers, QA, reviewers, whoever owns the document | Users, product, business owners, support, QA running real journeys |
How it fails | The specification was ambiguous, or the comparison was skipped | The requirement was wrong, or nobody watched a real user |
Cost of catching it late | Rises with every stage it survives | Rises fastest after release, once workarounds spread |
Read the third column twice. Verification is not an early phase that ends; validation is not a final phase that begins. A single release contains several of each, and the sequence matters more than the label.
What each one looks like on a project
Verification: reading a requirement before anyone writes code
Take one requirement: a password reset link stops working 30 minutes after it is sent. Verifying it never requires a browser. A reviewer checks that the acceptance criteria name the boundary explicitly, that the test cases include 29 minutes 59 seconds and 30 minutes 1 second, that the expiry value is read from configuration rather than hard-coded, and that the automated check asserts the rejection message rather than only the HTTP status. Every one of those is a comparison against something written down, and each one can be made before a single user touches the feature.
The same applies to a code review. The acceptance criteria say a guest checkout refuses an email that already has an account. The reviewer reads the handler, finds the duplicate check only runs for signed-in users, and records a defect. Nothing was executed. The finding is real, and it costs one conversation instead of one bug report.
Validation: trying the working flow the way a customer would
Now take the built product to a staging environment, open a fresh browser profile, and buy something as a returning customer with a saved card. The confirmation page appears immediately. The order list shows the order as pending, and it stays pending. Nothing here violates a written specification, because the specification never said how quickly the payment provider's confirmation had to arrive or what the shopper should see in the meantime.
That is a validation finding, and it is the kind of thing verification structurally cannot see. The reference point was not a document. It was a person who expected to know whether their money had left their account.
How the two fit inside one test cycle
A release that uses both looks roughly like this:
- Requirement review. Verification. Each requirement gets an explicit, checkable result. Anything vague is rewritten now, because vagueness later becomes an argument.
- Test design review. Verification. Every acceptance criterion has at least one case that can fail it, and the boundary values are written down rather than implied.
- Build-level checks. Verification. Unit and integration tests compare behaviour to criteria. Fast feedback, narrow scope.
- End-to-end run on the integrated build. Mixed by nature. The assertions are verification; the moment someone completes the flow by hand and reacts to what they see, validation has started.
- Acceptance and beta. Validation. People with a real stake use the thing without a script.
- After release. Validation. Support tickets, completion rates in the live flow, and the first workaround someone invents.
The two activities complement each other through a loop, not a handoff. Validation produces a finding the specification did not cover. That finding is turned into a written expectation, which makes it verifiable, and the next build is checked against it. Skip the middle step and the loop breaks: the fix gets made, nobody writes down what correct behaviour now means, and the same gap reopens two releases later under a different name.
There is a limit worth naming. Verification cannot save you from a requirement that was wrong when it was approved, because it measures against that requirement. Validation cannot prove internal consistency, because it only observes what surfaces in use. Neither is complete, which is exactly why a release needs both rather than the cheaper of the two.
Where teams mix them up, and what it costs
Using the words interchangeably in a status report. When a summary says tested and validated after a run of specification checks, stakeholders hear that real users are fine with the product. They are not being told that. The cost is a decision made on evidence that does not exist.
Treating a green regression suite as validation. Regression checks protect what already worked. They say nothing about whether anyone wanted the flow in the first place, and they rarely cover a first-time user's path through it.
Deferring all verification to the end. A review at requirement time costs one comment. The same defect discovered during acceptance costs a rewrite, a re-test, and a delay you have to explain. Verification is worth most where it is cheapest, which is early.
Assuming validation belongs to the customer. If the first person to use the flow as a user is a paying customer, then a customer is doing your acceptance work, in public, without a bug tracker.
Verifying without a written reference. Without an agreed specification, a review collapses into opinion, and the only remaining check is validation — the expensive one, run late, on people who did not ask to be test subjects.
Validating only the happy path. The second attempt, the expired session, the address that fails validation once and succeeds on retry. These are where real flows break, and they are invisible to a scripted first pass.
A short validation walkthrough on a real user flow
Here is the smallest version that still produces real evidence. The flow: a returning customer buys one item with a saved card. The expected result, written in one sentence before anything is run: the shopper reaches an order confirmation showing the order number and total, the order appears in their order history within a minute, and a confirmation email arrives within five.
Do it in a fresh browser profile so no cached state or saved session is quietly doing work for you. Use a build that has already passed verification, otherwise you are debugging two things at once. Walk the flow as a shopper would: sign in, pick the item, keep the saved card, submit, and then do nothing for a few minutes. Record what actually happened — the confirmation page, the order number, the order history, the email arrival time, and a screenshot of each. Then run it a second time, and once more with the network throttled, because the second attempt and the slow connection are where the flow usually exposes itself.
The completion standard is simple and it is not a feeling: you can state pass or fail with evidence another person could check, and if it failed, you can point at the exact sentence of the specification that was missing, ambiguous, or wrong. That last part is what turns a validation session into something the next build can verify.
A quick rule for knowing which one you just did
Look at your evidence, not at the activity's name. If you compared the result to something written down, you verified. If you compared it to a need, an expectation, or observed behaviour, you validated. Two common ambiguities: a demo (validation, if anyone reacted to what they saw; verification, if someone checked it against criteria), and an exploratory session (validation, even when it is done by a developer, because no written reference is in play).
Practically: if you had to look it up, you were verifying. If you had to try it, you were validating.
Once a team can answer that question about its own work without arguing, the two activities stop competing for the same slot in the calendar. Verification runs continuously and cheaply against the written record. Validation runs when a real need has to meet a real build. Together they answer a question neither can answer alone: not just whether the product matches the plan, but whether the plan was ever worth matching.
