L0Reference4 min read

Verification vs validation

Did we build it right, and did we build the right thing. The distinction sounds like exam vocabulary until an AI feature passes every assertion and is still useless to the person using it — at which point it becomes the most practical idea here.

Verification asks whether the product was built correctly against what was written down: the specification, the design, the acceptance criteria. Validation asks whether the thing built is the right thing for the person who has to use it.

The shorthand used across the industry is "did we build it right" for verification and "did we build the right thing" for validation. Together they are usually written as V and V.

An example makes the gap obvious.

A council built a wheelchair ramp at a library entrance.

It was inspected and signed off. The gradient matched the drawing, the handrail height was correct, the surface was the specified non-slip finish. Every measurement passed.

Nobody could use it. The ramp ended at a door that opened outwards, so a wheelchair user had to reverse down the slope to let the door swing past.

The build was verified. It was never validated. That is the entire distinction, and it sounds like exam vocabulary right up to the moment it costs you something.

The terms you will hear

Verification. Checking the product against a written statement about it. Automatable, repeatable.
Validation. Checking the product against a real need. Needs a person who understands the user.
Static testing. Verification without running anything: reviewing a spec, a design or code.
Dynamic testing. Verification by running the software.
Acceptance criteria. The written conditions a story must meet. The usual target for verification.

Two questions, not two documents

Verification compares the thing to a statement about the thing. Does the total match the sum? Does the field reject letters? Does the API return the documented shape? These are checkable, repeatable and easy to automate, which is why most test suites are pure verification.

Validation compares the thing to a need. Can a customer complete a refund without calling support? Does the summary tell a manager what they wanted to know? Is the ramp usable by somebody in a wheelchair?

You need both, and only one of them shows up green in a pipeline.

Why this got sharper

For a long time validation was somebody else's job, usually product. Verification kept testers busy, because building was slow enough that most defects were mismatches against the spec.

Now consider an AI feature. A summariser passes every assertion: it returns text, under the character limit, in valid JSON, in under two seconds. Every check is green. The summaries are also bland and omit the one number the reader needed.

Nothing is broken and the feature is worthless. That failure is invisible to verification, and it is why judging whether an answer is any good became a testing discipline rather than a product opinion.

How to do both deliberately

Verify against something written. Acceptance criteria, a schema, a policy document. If nothing is written, that is the first finding.
Validate against somebody real. Ask who uses this, then walk their actual task end to end, not the story's happy path.
Ask the validation question in refinement. "Who is going to use this, and what were they doing before?" Four minutes, and it prevents more waste than any test.
Watch one real user if you can. Ten minutes over somebody's shoulder beats a week of guessing. Support calls are the next best thing.
Report both kinds of finding separately. "It matches the criteria and it does not solve the problem" is a sentence worth saying plainly.
Keep the validation evidence. A note that says who you checked with, and when, belongs in the release record.

Verification is comparing the software to a document. Validation is comparing it to a person. Most teams have automated the first and skipped the second.

A worked example

For example, here is the same feature checked both ways, for the gift-card balance page at Willow Books.

v-and-v-balance-page.txt

FEATURE  gift card balance page

VERIFICATION (against WB-1803 acceptance criteria)
  shows the remaining balance                       pass
  works logged in and logged out                    pass
  invalid code shows a clear error                   pass
  balance updates after use                          FAIL, 60s cache
  page loads under 2 seconds                         pass
  keyboard navigable, axe clean                      pass

  verdict: 5 of 6 criteria met. one defect, accepted by product.

VALIDATION (against what people actually do)
  asked support what customers ask them about gift cards
    -> "they ask whether the card still works, and how much is left,
        usually while standing in a shop or on the phone to us"

  walked that task on a phone
    1  customer has the card code in an email from six months ago
    2  finds the email, copies the code with trailing whitespace
       -> page rejects the code. no trim. real people paste like this.  BUG
    3  code accepted. balance shown as "£25.00"
       -> does not say whether it expires, which is the second thing
          every caller asks support                                  GAP
    4  no way to see what was spent, so a customer who thinks the
       balance is wrong has to phone anyway                          GAP

  verdict: every criterion was met and the page does not answer the
  two questions customers actually ring up about.

Both columns are testing. The first is easy to automate and easy to report. The second needed one conversation with support and ten minutes on a phone, and it found the bug that will generate calls.

How to show you know it

A finding in each column for the same feature. The clearest possible demonstration.
A validation gap that came from talking to support. Cheap to get, and almost nobody does it.
A trailing-whitespace class of bug. Real people paste untidily. Finding that is validation, not verification.
A sentence separating the two. "It meets the criteria. It does not solve the problem." Say it once and people remember who said it.

Questions

Which one is more important?

Verification protects you from shipping something broken. Validation protects you from shipping something pointless. A team that only does the first builds correct software nobody wanted, and both failures cost real money.

Is validation not the product manager's job?

They own the decision about what to build. You are often the only person who walks the whole task on a real device before release, which makes you the one who notices the ramp ends at a door.

How do I validate when I cannot talk to users?

Talk to whoever talks to users: support, sales, onboarding. Read the tickets. Ten support conversations are a decent proxy and they cost you nothing.

Where does this fit with acceptance criteria?

Criteria are the verification target. Validation asks whether the criteria themselves were the right ones, which is exactly the question refinement exists for.