Verification vs Validation in Software Testing: Definitions, Examples & Table
Verification asks 'are we building the product right?' Validation asks 'are we building the right product?' Clear definitions, examples, a comparison table, and interview-ready answers.
Last updated: July 11, 2026 · 6 min read
The verification-vs-validation question shows up in almost every QA interview. This guide gives you the crisp definitions, a comparison table, and a real example so you can answer it confidently. Pair it with our Manual Testing Complete Guide.
The two definitions
Verification — checking that the software conforms to its specification. Static, document- and code-based. "Are we building the product right?"
Validation — checking that the software meets the customer's actual needs. Dynamic, requires running the product. "Are we building the right product?"
Verification vs validation — comparison table
| Aspect | Verification | Validation |
|---|---|---|
| Question | Are we building the product right? | Are we building the right product? |
| Type | Static | Dynamic |
| Activities | Reviews, walkthroughs, inspections, static analysis | Functional, integration, system, UAT testing |
| Focus | Documents, design, code | Running application |
| Cost of defect fix | Cheap — caught early | Expensive — caught late |
| Who does it | Devs, architects, QA analysts | QA engineers, end users |
| Example | Reviewing an API spec against acceptance criteria | Testing the deployed API returns the correct data for a customer scenario |
Concrete example: a login feature
Verification activities:
- Review the user story for completeness
- Inspect the sequence diagram for the auth flow
- Static analysis of the JWT signing code
- Peer review of the pull request
Validation activities:
- Execute manual test cases for valid, invalid, and edge inputs
- Run automated regression on the login page
- User acceptance testing with a real customer persona
- Production monitoring of login success rate
How they fit into the V-model
The classic V-model pairs each development phase (left side) with a testing phase (right side). Verification activities live on the left — reviews, static analysis. Validation activities live on the right — unit → integration → system → acceptance testing. See our test pyramid guide for a modern take.
How to answer in an interview
"Verification is static — reviews, inspections, static analysis of the artifacts we produce. It's cheap and catches defects early. Validation is dynamic — actually running the product to confirm it solves the user's problem. You need both: verification without validation ships a technically-correct product no one wants; validation without verification ships a product with expensive late-stage rework."
Continue your learning
Verification & validation in a modern DevOps team (2026)
The textbook definitions haven't changed since Boehm coined them in 1979 — but the practice looks nothing like a V-model diagram today. Here is how a mature 2026 engineering org actually allocates verification and validation effort across a release, based on aggregated data from the DORA State of DevOps reports and our own 2026 SoftwareTestPilot flake-rate survey.
| Stage | Verification activity | Validation activity | Typical cost of a missed defect |
|---|---|---|---|
| Design | Threat modeling, API contract review | — | $100 |
| Code | Linter, TypeScript, code review | Unit test on every save | $500 |
| PR / CI | SonarQube, security SAST | Component & integration tests | $2,000 |
| Staging | Config & IaC drift review | Playwright E2E, contract tests | $8,000 |
| Production | Runbook review, observability audit | Synthetic monitoring, feature-flag canary | $40,000+ |
Two lessons follow: verification is cheap, so make it habitual (pair reviews, contract-first design, ADR docs); validation costs rise 10x per stage, so push validation as far left as your team can afford. Teams that skip verification on the design of a payments feature routinely lose a full sprint reworking a validated-but-wrong implementation.
Worked scenario: a 3-line requirement, two very different tests
Requirement: Users on the annual plan get a 20% discount at renewal.
- Verification test (static): Peer-review the PR that adds the discount rule. Does the SQL join include cancelled-but-not-expired subscriptions? Does the code path handle currency correctly? No app is running.
- Validation test (dynamic): In staging, seed an annual subscription due to renew tomorrow, run the renewal job, and assert the invoice line item is 20% lower than the sticker price. The app is running with real data.
Both catch different bugs. Verification catches the SQL join defect. Validation catches the currency-rounding defect that made the discount 19.99% for JPY. Ship both or ship broken.
Common interview follow-ups
- Give a verification activity a QA lead owns — reviewing the test plan against the acceptance criteria before execution begins.
- Where does exploratory testing sit? Validation. It runs against a live build.
- Is contract testing verification or validation? Both, depending on when it runs. Consumer-driven contract review of the schema = verification. Running Pact tests against a live provider = validation.