Verification vs Validation

Verification in detail

Verification asks: did we build what we said we would build? You need something written to compare against: a requirement, a user story with acceptance criteria, a design file, an API spec, a regulation.

Static verification: checking without running anything

Static testing means examining a work product without executing it. The work product can be a user story, a design, a test plan, or code. Common forms, from most informal to most formal:

Developers also use static analysis tools that scan code for problems (unused variables, security weaknesses) without running it.

Dynamic verification: running tests against the spec

Most of your test casesTest caseA written set of steps, data and an expected result used to check one specific behavior.Open in glossary → are verification. Each one has an expected result taken from the spec:

• The password field rejects “abc12” because the acceptance criteria say “at least 8 characters”.
• The coupon SAVE10 reduces the subtotal by exactly 10%.
• The transfer limit of $1,000 per day is enforced, including at exactly $1,000 (see Boundary value analysis).

If the result matches the spec, the test passes. Whether the spec itself makes sense is a different question.

Validation in detail

Validation asks: did we build something people actually need, that works for them in real life? The pass/fail judgment comes from users and their goals, not from a document.

Common validation activities:

• User acceptance testing (UAT)User acceptance testingReal users or business people checking the product meets their needs before release.Open in glossary →. Real users or business people try the product with their everyday tasks and decide if it is fit for purpose. For example, a bank’s branch staff try the new standing-order feature with real customer cases. See Levels of testing.
• Usability testingUsability testingChecking how easy and pleasant the product is for real people to use.Open in glossary →. Watching real people try tasks and noting where they hesitate, misunderstand or give up.
• Beta testingBeta testingTesting a pre-release build with a group of testers or real users before store release.Open in glossary →. A pre-release build goes to a group of real users through TestFlight or Google Play testing tracks. See Beta distribution.
• Demos and prototype feedback. Showing a clickable prototype or a sprint demo to the product owner or customers: “Is this what you need?”
• After launch: app-store reviews, support tickets and analytics show whether the feature really solves the problem.

Static vs dynamic testing

These two terms describe how you test, and they overlap with verification and validation in a way that confuses many beginners.

	Static testing	Dynamic testing
Runs the software?	No	Yes
Examples	Story reviews, design walkthroughs, code reviews, inspections	Running test cases, exploratory testing, usability sessions, UAT
Finds	Defects in documents and code: gaps, contradictions, ambiguity	Failures in the running product
Mostly serves	Verification	Both verification and validation

When they disagree

The interesting cases are the ones where a product passes one check and fails the other.

Passes verification, fails validation

Passes validation, fails verification

Less common, but real:

• The beloved but non-compliant feature. Users love the new one-tap “Buy now” button. But the spec (and consumer law in many countries) requires showing the total including fees before payment. Users are happy; the product fails verification and could get the company fined.
• The good-enough rounding. Customers never notice that a currency converter rounds to 1 decimal instead of the specified 2. It “works” for them, but it breaks the agreed rule and adds up to real money across millions of transactions.

In both cases the fix is to bring the product and the spec back in line, either by changing the product or, if the users are right, by updating the spec.

How testers contribute to both

A manual tester isn’t just “the verification person”. You help on both sides.

VerificationValidation

• Review stories and acceptance criteria early. Ask “what happens if…?” for empty, maximum, invalid and interrupted cases. Use Equivalence partitioning and Boundary value analysis to spot missing rules.
• Review designs. Are all states there: loading, empty, error, disabled? See Button and Text field.
• Write test cases that trace back to requirements, so every rule is checked. See Writing test cases.
• Run them and report mismatches with clear bug reports.

• Think like a real user during exploratory testing: “would my mom understand this screen?”
• Report usability concerns even when the spec is met. Label them clearly as “matches spec, but confusing” so the team can decide.
• Bring real-world context: small phones, bad networks, interruptions, one-handed use, screen readers. See Interruptions and Accessibility basics.
• Support UAT and beta: prepare environments and test data, collect and triage user feedback.