The difference between verification and validation is the question each one answers. Verification asks "are we building the product right?", meaning does the software match its specification, design and standards. Validation asks "are we building the right product?", meaning does it meet the real needs of the people who will use it. Software can pass every verification check and still fail validation, which is how teams deliver a product that works as specified and that nobody wants to use.
The difference between verification and validation, in plain terms
The two questions are usually credited to the software engineer Barry Boehm, and they have lasted because they are hard to improve on.
Verification compares the work with something you wrote down: a requirement, a design, a coding standard, an acceptance criterion. The evidence comes from inside the team. Either the thing conforms or it does not.
Validation compares the work with reality: a user trying to get something done, a business outcome, the environment the product has to run in. The evidence comes from outside the team, and it is often less tidy.
Suppose a specification says "the monthly report can be exported as a CSV file". Verification confirms that the export button produces a correct CSV with the right columns. Validation is where you find out whether the finance team can load that file into their accounting package without reworking it by hand every month. The first check can pass for years while the second one fails.
Put another way, verification can only ever be as good as the specification it checks against. Validation is how you test the specification itself.
Verification and validation compared
| Verification | Validation | |
|---|---|---|
| The question | Are we building the product right? | Are we building the right product? |
| Compared against | Specifications, designs, standards, acceptance criteria | User needs, intended use, business outcome |
| Evidence comes from | Inside the team | Users, customers and live operation |
| Typical activities | Reviews, static analysis, unit and integration tests, system tests against requirements | User acceptance testing, usability testing, prototypes, beta releases, pilots |
| Needs working software? | No. Documents and code can be checked by review and analysis | No. A prototype or mock-up can be put in front of users |
| Who leads | Engineers and testers | Product owners, designers, customers |
| Can it be automated? | Largely | Only at the edges, through analytics and experiments |
| What failure looks like | Defects and deviations from the specification | A correct product that is ignored, or used only with workarounds |
| When it happens | On every change | Before building, at milestones and after release |
Verification activities, with examples
Reviews
Requirements reviews, design reviews and code reviews are verification without running anything. They are also the cheapest kind. A requirements review that catches two rules contradicting each other costs a conversation. The same contradiction found after release costs a rebuild.
Static analysis
Type checkers, linters, dependency checks and security scanners inspect the code against a set of rules without executing it. They are tireless, consistent and narrow. They will catch every unused variable and no misunderstood requirement.
Unit and integration tests
These execute the code and compare the result with what the specification says should happen. Run automatically in a CI/CD pipeline, they are the backbone of verification on most teams, because they repeat the same checks on every change without anyone remembering to.
How those tests are designed, from the requirements or from the code, is its own subject. I cover it in white box vs black box testing.
Validation activities, with examples
User acceptance testing
In user acceptance testing, or UAT, the people who will use the system run their real tasks on it and decide whether it is fit for them. The value lies in the word "their". When UAT consists of users re-running scripts written by the development team, it has quietly turned back into verification, and it will find very little.
Usability testing
Give a few representative people a task, say nothing, and watch where they hesitate. It needs no finished software. A clickable prototype is enough, which makes this one of the cheapest forms of validation available, and a good reason to involve UX design before the build starts.
Beta releases and pilots
A beta release puts the working product in front of a limited group under real conditions: their data, their devices, their habits, their impatience. No test environment reproduces those. After full release, usage analytics and support requests carry validation on indefinitely.
An MVP belongs here too. Its purpose is validation: the smallest product that can show whether the need is real before the full cost is committed.
Working through this on a real project?
Tell us what you are building or fixing. A senior engineer will give you a straight view of it, including when the honest answer is that you do not need us.
Verification and validation in software testing: where each one sits
The traditional picture is the V-model. Each level of specification on the way down is paired with a level of testing on the way up. Unit tests verify the detailed design, integration tests verify the architecture, system tests verify the system requirements, and acceptance testing validates the user requirements at the very end.
The picture is useful, and it has caused one lasting misreading: that validation is a phase at the end. If the first time a user sees the product is after it has been built, validation can only deliver bad news late. In an iterative process both run from the first week.
- Discovery. Validation leads, through interviews, observation and prototypes. Verification is already present, as a review of whether the requirements are consistent and testable.
- Build. Verification leads, through code review, static analysis and automated tests. Validation continues by putting each increment in front of someone who will use it. A demo to a stakeholder is weak validation. A user completing a real task is strong validation.
- Pre-release. System testing verifies against the requirements. UAT and usability sessions validate against the need.
- After release. Monitoring and regression tests keep verifying. Usage data and customer feedback keep validating.
The economics are simple. The later you learn that you built the wrong thing, the more perfectly verified code you throw away.
Why teams over-invest in one and neglect the other
Too much verification
Engineering-led teams drift this way. Verification is measurable, automatable and entirely within the team's control. A green pipeline feels like progress. Validation means talking to users, which is slower, more awkward and returns ambiguous answers.
Commercial terms can reinforce the habit. When software is bought against a fixed specification, the supplier is paid for conformance to that document, so both sides end up optimising for verification. It is one of the trade-offs to weigh in fixed price versus time and materials. The usual result is a system delivered on time and to specification that people work around.
Too much validation
Early-stage product teams drift the other way. They interview constantly, demo often, and learn quickly what customers want. Then the prototype that proved the idea becomes the production system, with no tests and no review behind it.
The need has been validated. The software has not been verified. Customers want the product, and it loses their data. The bill arrives later as technical debt.
In my view the first failure is the more expensive of the two, because it tends to be discovered last. The second is the more visible, because customers watch it happen. Neither is a reason to drop the side you are already good at. Both are a reason to fund the other.
Verification and validation in regulated industries
In medical devices, pharmaceuticals, aerospace, automotive and rail, these words are formal terms with defined meanings. Regulators and auditors generally expect both to be planned, carried out and documented as distinct activities. The details vary a great deal, but some patterns recur.
- Traceability. Each requirement is linked to the tests that verify it, and each user need to the evidence that validates it.
- Recorded evidence. A check that was performed but not documented does not count.
- Independence. The people checking are separated from the people building. In the highest-risk work a separate organisation may do it, known as independent verification and validation.
- Validation under conditions of real use. Representative users, in an actual or simulated operating environment.
- Change control. A change triggers re-verification, and re-validation where it affects intended use.
The vocabulary also shifts between sectors. In pharmaceuticals, for instance, "validation" often serves as an umbrella term for the whole documented effort of showing that a computer system is fit for its intended use, including work an engineer would call verification.
The exact obligations depend on the sector, the jurisdiction and the risk class of the product. Take them from the applicable standard and your quality or regulatory lead, not from an article like this one.
How to do both on a small team
You do not need a QA department or a research function. You need both questions asked on a regular rhythm.
- Write acceptance criteria before building. This gives verification something to check against. If the customer is in the room when they are written, it is also your first act of validation.
- Automate the verification you repeat. Type checking, linting and tests on the core logic, run on every change. Not everything, only the paths where a defect would cost money or trust.
- Have a second person review every change. It is the cheapest verification there is, and it spreads knowledge of the code.
- Show a prototype to real users before the expensive part. A handful of sessions is usually enough to surface the largest problems.
- Release to a small group first. A beta list or a feature flag turns launch from a single bet into a controlled test.
- Pick one outcome per feature and check it after release. Did anyone use it? Did the thing it was meant to improve actually move?
- Keep the two questions apart in reviews. "Does it meet the criteria?" and "were the criteria right?" deserve separate answers.
If I could only add one habit to a team that already tests its code, it would be the fourth. If the team already talks to users constantly, it would be the second.
FAQ
What is the difference between validate and verify?
To verify is to confirm that something matches a stated reference. To validate is to confirm that it is fit for its purpose. Everyday usage is looser. Checking that an email address is correctly formed is usually called validation, while confirming that the person owns it, by sending a link, is called verification. Form "input validation" is a check against rules, so in the engineering sense it sits closer to verification.
What does verification and validation mean in software testing?
Verification and validation, often shortened to V&V, is the combined set of activities that shows software is both built correctly and suitable for its users. Verification covers reviews, analysis and testing against specifications. Validation covers acceptance testing, usability testing and trials with real users.
Which comes first, verification or validation?
Neither waits for the other. Validation of the idea should begin before any code exists, and verification begins as soon as there is a document to review. After that they run side by side until the product is retired.
Is testing verification or validation?
It depends on what the test compares against. A test against a specification is verification. A test against a user's real need is validation. Some textbooks use a narrower convention, where verification means static checks without running the code and validation means all dynamic testing. If your course or auditor uses that definition, follow it.
Is UAT verification or validation?
Validation, provided real users are carrying out real tasks. If they are following test scripts written by the delivery team, it is closer to a second round of verification.
If you want both questions built into how your product is delivered, that is how we approach QA and software testing.