A search feature that returns results in 3 seconds passes verification: it meets the requirement. It fails validation: users are comparing it to Google's 0.3 seconds and find it unacceptably slow, even though the spec never said otherwise. This article covers the distinction between the two, where each testing activity falls on the spectrum, and why catching only verification failures leaves an entire category of defects untouched.
The short definitions
Verification checks whether the product conforms to its specifications. Does it match what was documented, designed, and agreed upon? Validation checks whether the product meets the actual user's needs. Does it solve the real problem it was built to solve?You can have a product that passes verification but fails validation: it works exactly as specified, but the specification was wrong — it doesn't do what users actually need.
You can also have a product that passes validation but fails verification: users love it and it works great, but it has undocumented features, security holes, or behaviors that differ from the spec.
Verification: does it match the spec
Verification activities are usually done without executing the software. The question is: does what we built match what was agreed?
What verification looks like
Document reviews- Does the requirements document cover all agreed features?
- Is the design spec consistent with the requirements?
- Do test cases cover all the requirements?
- Does the code implement what the design document says?
- Are there security patterns from the coding standards?
- Walk through the requirements, the design, and the implementation together. Does everything align?
- Does the UI wireframe match the agreed user stories?
The goal
Find defects in the documents and designs before the software is built or tested. It's cheaper to fix a wrong requirement on paper than to fix it after 3 sprints of development.
Validation: does it solve the real problem
Validation is done by executing the software — usually through actual testing. The question is: does this product work for the people it was built for?
What validation looks like
User acceptance testing (UAT)- Real users or stakeholders test the software against their actual workflows
- "Does this do what I needed it to do?"
- Test the complete, integrated system against requirements, but also against user goals
- Does the whole thing actually work end-to-end for realistic use cases?
- A subset of real users use the product in their real environment
- Uncovers gaps that spec-based testing missed because the spec didn't capture real usage
- Can users actually accomplish their goals with this interface?
- Even if technically correct, is it usable?
The goal
Confirm that the software delivers real value. A feature can be technically correct and completely useless.
A concrete example
Imagine a requirement:
"The search field must return results within 3 seconds."Verification question: Does the implementation match this requirement? We test: run a search, measure the time, confirm it's under 3 seconds. Pass. Validation question: Does this solve the user's actual problem? We discover: users are searching huge product catalogs and 3 seconds feels unacceptably slow when Google returns results in 0.3 seconds. Even though the spec said 3 seconds and the code meets that, validation fails.
The specification was wrong. Verification caught nothing. Validation caught everything.
This is why you can't rely solely on verification — the spec is only as good as the people who wrote it.
Another example: form validation
Requirement: "The password field must not accept fewer than 8 characters."
Verification: Test that a 7-character password is rejected. It is. Validation: A real user tries to use their usual 6-character password, gets rejected, tries to create a new 8-character one, but the error message just says "Invalid input" with no explanation. They give up and don't register. Validation fails — the product doesn't help users accomplish the goal of registering.The code was correct. The requirement was too narrow. It didn't account for the user experience of the error message.
How they appear in a development lifecycle
| Phase | Activity | Verification or Validation? |
|-------|----------|----------------------------|
| Requirements | Requirements review: checking for completeness, consistency | Verification |
| Design | Design walkthrough: checking design matches requirements | Verification |
| Development | Code review: checking code matches design | Verification |
| Testing | Unit tests: checking components work as specified | Verification |
| Testing | Integration tests: checking modules work together | Verification |
| Testing | System tests: checking full system meets requirements | Both |
| Testing | UAT: checking real users can accomplish real goals | Validation |
| Release | Beta testing: real-world usage | Validation |
Most of what QA engineers do in daily work is a mix of both — you run tests against requirements (verification) while also thinking about whether the feature actually works for real users (validation).
Why this distinction matters
Bugs from verification failures: Implementation doesn't match the spec. A button doesn't do what the requirement says it should. A calculation is wrong. A field accepts values it shouldn't. Bugs from validation failures: The spec was incomplete or incorrect. The feature works as designed but fails in real user scenarios. Missing error messages, confusing flows, performance that's technically acceptable but practically terrible.Good QA catches both. Pure spec-based test execution catches verification failures. Exploratory testing, usability reviews, and UAT catch validation failures.
The interview version
If you get this in an interview:
Verification = "Are we building the product right?" Conformance to specifications, typically static (reviews, walkthroughs) or early-stage testing against documented requirements. Validation = "Are we building the right product?" Confirmation that the software meets user needs, typically through executing the software in realistic conditions (UAT, beta testing, usability testing).The classic analogy: a map can be accurate (verification — it correctly depicts the terrain) but useless (validation — it shows the wrong destination). You need both a correct map and the right destination.
Both concepts are relevant to every QA engineer's work, even if you never use the terms explicitly. Whenever you're checking "does this match the requirement," you're doing verification. Whenever you're asking "does this actually work for a real user," you're doing validation. The best testers keep both questions running simultaneously.
→ See also: Black-Box vs. White-Box Testing: A Clear Guide for QA Engineers | Acceptance Testing: What It Is, Who Does It, and How | What Is Manual Testing? The Complete Guide for 2026
