Verification and validation
Verification and validation are the two questions a quality process has to answer. Verification asks whether the software was built correctly against its specification. Validation asks whether that specification described the right thing. Software can pass one and fail the other, which is why both are checked, usually by different people.
The longer version
The shorthand most people learn is that verification means building the product right and validation means building the right product. It survives because it is accurate. Verification compares the thing to its description, and every activity that does so belongs to it: code review, static analysis, unit and integration tests, walkthroughs of a specification against a design. Validation compares the description to the need, and it cannot be done by reading the specification, because the specification is the thing under examination.
That difference decides who can perform each. Verification can be done by the team, because it needs knowledge of what was asked for and how it was built. Validation needs somebody who holds the problem rather than the solution: a user, a client, a product owner. This is why user acceptance testing exists as a separate stage rather than as the last item on the engineering checklist.
The vocabulary came from engineering disciplines where the two are formally separated, and it is used most strictly in regulated software, where an audit expects to see evidence of each kept apart. Outside those settings the terms are used loosely, and the pair is often reduced to a single word. The distinction is still worth keeping, because the failure it describes is common: a team verifies thoroughly, ships something that meets every stated requirement, and finds that the requirements were wrong.
In practice the two run alongside each other rather than in sequence. Verification is continuous, because it is what the test suite and the review process do on every change. Validation is intermittent and happens whenever the work is put in front of somebody who can say the need was misread, which is cheapest early and most expensive the week before a release.
Common questions
What is the difference between verification and validation?
Verification checks the software against its specification: was it built correctly. Validation checks the specification against the need: was the right thing specified. Verification is performed by the team, validation by whoever holds the problem, and software can pass either one while failing the other.
Which comes first, verification or validation?
Neither, strictly. Verification runs continuously, because the test suite and code review perform it on every change. Validation happens whenever the work can be shown to somebody who can judge whether it addresses the real need, and doing that early is the point rather than a nicety.
Is testing verification or validation?
Most testing is verification, because it compares behaviour against what was specified. User acceptance testing is validation, because the people running it judge whether the specified behaviour actually solves their problem. The same activity can be either, depending on what it is being compared against.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.