Verification vs validation: the question almost nobody knows how to answer

A team wraps up the sprint, runs the full suite, everything comes back green. They deploy with confidence. A week later the client writes: "this isn't what we asked for." Nobody lied. The software does exactly what the code says, and the code does exactly what the ticket said. The problem is that the ticket was wrong from the start. That team verified flawlessly. What it never did was validate.

Verification and validation are the two questions that hold up all of software quality, and they get confused constantly. They boil down to one line worth memorizing: verification asks "are we building the product right?"; validation asks "are we building the right product?". They sound almost identical. They are not. And grasping the difference is what explains why real QA starts in the requirements document, not in the code editor.

01 · the two questionsBuilding it well is not the same as building the right thing

The distinction is easy to state and hard to live. Verification checks that the product meets its specifications: that what you built matches what was written for you to build. Validation checks that those specifications were the right ones: that the product solves the user's real need. The first looks inward, against the document. The second looks outward, against reality.

ISO/IEC/IEEE 29119, the international standard for software testing, keeps them carefully apart. Verification is the confirmation, through objective evidence, that the specified requirements have been met. Validation is the confirmation that the requirements for a specific intended use have been met [1]. Notice the nuance: in one case the judge is the specification; in the other, actual use.

Verification tells you whether you followed the blueprint. Validation tells you whether the blueprint was worth anything.

A household example brings it down to earth. Someone asks for a ladder to reach the roof. The carpenter builds it with perfect measurements, solid wood, even rungs: verification passed, the ladder matches the blueprint. But the roof was five meters up and the ladder is three. Validation failed: a well built object that does not solve the problem. No stress test would have caught that, because the defect is not in the construction but in what was decided to be built.

02 · where each one livesVerification is internal; validation looks at the user

Because the two questions point to different judges, they are carried out with different techniques and at different moments in the cycle. Confusing them makes a team believe it is covered when it has only covered half.

Verification tends to be static and early. Requirements reviews, design reviews, code inspections, static analysis, unit and integration tests: all of it checks, with no need for an end user, that each piece meets what its specification asked for. It is cheap and done continuously, because every artifact (the spec, the design, the module) can be compared against the previous one as soon as it exists.

Validation tends to be dynamic and late. System tests against real scenarios, acceptance tests with the client, betas, demos with actual users. Here reading a document is no longer enough: you have to run the product under conditions close to its real use and observe whether it truly solves the need. That is why validation cannot be fully "moved up"; it needs something working and a real person in front of it.

An uncomfortable practical consequence follows. You can have one hundred percent test coverage and the wrong product. Coverage measures verification: how much of the code you exercise. It says nothing about whether that code solved the right problem. That is why "all tests pass" should never be confused with "the product is ready".

03 · why QA starts in the specThe most expensive defect is born before any code is written

If validation asks whether we built the right thing, then the most profitable moment to ask that question is before building. And that is where verification and validation shake hands at a point almost nobody looks at: the requirements document.

A requirement can be verified (is it well written, is it clear, is it testable, does it not contradict another?) and it can be validated (is this requirement, even if perfectly worded, really what the user needs?). When a team reviews the spec holding both questions, it catches the most expensive error of all: the wrong requirement. Because that error, if it survives the spec, spreads to the design, the code and the tests, and by the time someone notices it in a demo it has already cost weeks of well done work on a bad foundation.

The classic data from software engineering always point in the same direction: the later a defect is caught, the more it costs to fix, and a defect introduced in the requirements and discovered in production can cost orders of magnitude more than if it had been caught in the requirements phase [2]. An ambiguous requirement reviewed in time is fixed with a conversation. The same requirement discovered after launch is fixed with a redesign.

None of this takes anything away from verification. A product that solves the right problem but is badly built is useless too: it crashes, it is insecure, it is impossible to maintain. The lesson is not to choose one question over the other, it is that you need both and that they fail in different ways. Verification protects you from building badly. Validation protects you from building the wrong thing. A team that only verifies ships flawless software that helps no one; one that only validates ships good ideas poorly made.

The next time someone says "we already passed all the tests", it is worth asking which of the two things was tested. If all that was checked is that the code meets the spec, it was verified. Whether the spec was the right one remains an open question, and it is almost always the most important one.