What Validation Is, the Definition That Practice Ignores

Validation confirms that a product meets the need it was built for. It happens once the product has been implemented and is being used in real terms, under real conditions. It is not a final round of tests, and it is not a list of completed activities. It is the point where the need and the product finally meet each other.

What validation depends on

Validation depends on the user knowing two things: the criteria for success and the limits of the work. Without them, nobody can judge a result. A product cannot be validated by someone who does not know what good looks like or where the operating limits sit.

The plan for validation is set early. Each requirement needs its criteria and limits written down when the requirement is written, so that real use can later be read against them. The validation itself still waits for real use. Trials before that are a start. The full verdict comes from service, because trials are usually shorter and more controlled than the real thing.

Validation is not verification

Verification compares the product with its baseline. It confirms the product was built as designed. Validation compares the product with the need, in real conditions. It confirms the design was right.

These cannot stand in for each other. If validation is carried out by comparing the product with its baseline, it has become verification under another name. The product stays in verification mode, repeatedly confirming that it matches itself and never asking whether it does the job.

How practice drifts

Practice drifts toward verification because verification is easier. Tests are written from the design and run against the specification. They pass because the design matches itself. Everything looks complete. The question validation exists to answer has not been asked.

What a failure means

If a product fails validation, something was wrong at the start. Provided it was built to its specification, installed correctly and used within its limits, then either the specification or the requirement was wrong. Without that proviso, the conclusion is too broad. A product can also fail through a build defect, an installation error or use outside its limits, and those are different problems.

The two possibilities differ. If the requirement was wrong, the need was misunderstood. If the specification was wrong, the need was understood but the design answered it badly. The fix is different in each case. A wrong requirement sends the work back to the need. A wrong specification sends it back to the design.

The delta

The outcome of validation should not be a bare pass or fail. It should be the delta, the gap between what was achieved and what was needed. If there is no gap, the defined capability has been met. If there is a gap, it becomes design work, aimed at closing it. This gives validation a useful output. It tells the next engineer exactly what remains to be done.

Why it matters

The gap between a design that passes its tests and a design that works stays invisible until the product is in use. A design can satisfy every check and still not do what was needed. Validation is the step that finds this out. Skipping it, or replacing it with verification, does not remove the gap. It only delays the moment someone discovers it.

A plain test

There is a simple way to check whether validation exists. Ask what result would show that the intent was not met. If nobody can answer, validation has not been defined, however many tests have been run.

The only step that can say the requirement was wrong

Validation is the one step that can show the requirement itself was wrong. Every earlier check measures against the requirement, so none of them can question it. Only real use, against the real need, can. That is why validation cannot be shortened, and why it cannot be replaced by comparing a product with its own baseline.