Verification vs Validation
Verification and validation are two distinct quality activities that are often confused. They answer different questions: verification asks 'did we build the software right?', validation asks 'did we build the right software?'. Both are required for a quality product — and missing either one leads to different kinds of failure.
The Core Distinction
- Verification: Are we building the product RIGHT? — Checks that the software conforms to its specification. Static or dynamic.
- Validation: Are we building the RIGHT product? — Checks that the software meets user needs and business goals. Always involves real users or real scenarios.
- Verification without validation: Software perfectly implements the spec, but the spec was wrong or user needs changed.
- Validation without verification: Software meets user needs but has code quality issues, security holes, or technical debt.
- Real example: A banking app correctly implements the spec (verification ✅) but the spec says transfers can go negative (validation ❌ — fails user needs).
Verification vs Validation Examples
// ── VERIFICATION: Does it match the spec? ─────────────────────
// Spec: "Maximum file upload size = 10 MB"
// Verification test — does code enforce exactly 10 MB?
test("rejects files over 10MB", async () => {
const file11MB = generateFile(11 * 1024 * 1024); // 11MB file
const res = await uploadFile(file11MB);
expect(res.status).toBe(413); // 413 = Payload Too Large
});
test("accepts files exactly at 10MB limit", async () => {
const file10MB = generateFile(10 * 1024 * 1024);
const res = await uploadFile(file10MB);
expect(res.status).toBe(200);
});
// If these pass: verification ✅ — code matches spec
// ── VALIDATION: Does it meet USER needs? ──────────────────────
// User research reveals: average user uploads profile photos = 2-3MB.
// But video testimonials = 80MB. Users NEED to upload large files.
// Despite verification passing, the product FAILS validation.
// Validation discovered via:
// - User acceptance testing (UAT) sessions
// - Beta user feedback: "I can't upload my product video!"
// - Analytics: 42% of upload attempts fail (files > 10MB)
// Fix: Raise limit to 100MB for video-type files
// Now both verification AND validation are satisfied.
// ── Classic V&V Failure: NASA Mars Climate Orbiter (1999) ──────
// Verification ✅: Software correctly implemented the specification
// Validation ❌: Specification had wrong units (pounds-force vs. newtons)
// Result: $327M spacecraft destroyed on Mars arrival
// Lesson: Validating the spec itself is as important as validating the codeCommon Mistakes
- Only doing verification — passing all tests but shipping a product users hate because developers tested the spec, not user needs.
- Only doing validation — happy users who discover security vulnerabilities, data losses, or system crashes in production.
- Not involving users in UAT — user acceptance testing done only by internal stakeholders is verification dressed as validation.
- Treated as separate phases — V&V should run in parallel throughout development, not as sequential gates.
Tip
Tip
Practice Verification vs Validation in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Playwright rising fast — modern API, auto-waits, all browsers
Practice Task
Note
Practice Task — (1) Write a working example of Verification vs Validation from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Verification vs Validation is skipping edge case testing — empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Verification and validation are two distinct quality activities that are often confused.
- Verification: Are we building the product RIGHT? — Checks that the software conforms to its specification. Static or dynamic.
- Validation: Are we building the RIGHT product? — Checks that the software meets user needs and business goals. Always involves real users or real scenarios.
- Verification without validation: Software perfectly implements the spec, but the spec was wrong or user needs changed.