Verification and validation
Two questions that sound identical and are not: did we build it right, and did we build the right thing?
- You can place any test you're planning on the V-model and say what it actually proves.
- You know the three ways a test suite lies: testing the mock, testing the plan, and testing what's easy.
Verification asks whether the system conforms to its specification. Validation asks whether the specification was the right one — whether the thing, when used by real people in the real environment, satisfies the need that started all this. You can pass every verification test and still fail validation, and that is the most expensive failure a project can have, because everything looked green.
| Verification | Validation | |
|---|---|---|
| Question | Did we build it right? | Did we build the right thing? |
| Measured against | Requirements and design | Stakeholder needs and intended use |
| Who | Testers, reviewers, independent eyes | Users, operators, the sponsor |
| Example | "Does the API return the documented schema?" | "Does this actually reduce support backlog?" |
| Fails how | Red test, missing feature | Adopted by nobody; used wrongly; harms someone |
A support team cannot keep up at night. Written as a need: "customers get a correct answer within five minutes, at any hour, for the top 80% of questions."
Validation is designed here, not at the end: acceptance means the backlog actually falls without satisfaction dropping.
Break the need into testable behavior: answer latency, escalation threshold, citation requirement, audit logging, refusal rule.
Each line gets an acceptance method now. A requirement with no method is a future argument.
Decide the elements: retriever, generator, guardrail, escalation queue, logger. Allocate each requirement to an element so you know where to test it.
Build the pieces. Unit tests confirm each piece behaves as its own spec says — not that the system works.
Tests at each level answer to the level above: unit tests to detailed design, subsystem tests to architecture, system tests to requirements. A passing unit suite proves the smallest thing only.
This is where interface bugs appear — the ones no unit test can see.
Run it in the real environment with real users: does the backlog fall, do customers accept the answers, do agents trust the escalations? This is the only test that can fail while everything else passes.
7.1Four ways to prove something
| Method | What it is | Use it for |
|---|---|---|
| Inspection | Read it and compare to the spec | Documents, interfaces, configuration, code structure |
| Analysis | Calculate or model it | Capacity, cost, failure propagation, performance predictions |
| Demonstration | Operate it and watch | Workflows, integrations, user journeys |
| Test | Controlled conditions with measurements | Anything with a number: latency, accuracy, throughput, error rate |
Mixing them is normal, and cheaper than testing everything. A p95 latency requirement might be analyzed early, tested at system level, and monitored forever after. What's not acceptable is "we're confident" as a method.
7.2The matrix that keeps it honest
REQ-ID requirement method evidence status
REQ-011 dashboard renders < 2.0 s p95 test load-2026-03 pass
REQ-012 onboarding < 3 min, no support demonstration 5-user study fail → 4.5 min
REQ-021 repeated query < 10 ms analysis cache model pass
REQ-031 99.9% monthly availability analysis+test 30-day soak pending
REQ-032 failover within 5 s test chaos run 12 pass
REQ-041 refuses out-of-scope requests test red-team set passTwo things make this matrix worth maintaining. It links every requirement to evidence, and it makes failures visible in a place a non-engineer can read. A requirement whose status has been "pending" for three sprints is not untested — it is unowned.
Whoever wrote the code is the worst person to decide whether it meets the requirement, because they already know what it does. Independent verification doesn't require a separate department — it requires someone who reads the requirement first and the implementation second.
Three ways a suite lies: testing the mock (the fake behaves, the real dependency doesn't), testing the plan (you verify the architecture you intended, not the one in production), and testing what's easy (coverage grows where code is simple). None of these show up as a red build. The antidote is a small number of end-to-end tests against real interfaces, run often, plus production checks on the requirement that matters most.
Every requirement passes its test, but users abandon the product in week two. What did you skip?
60-second recap
- Verification: built it right. Validation: built the right thing. Only validation can fail while everything is green.
- Every level of decomposition has a matching verification level. No partner means no proof.
- Four methods: inspection, analysis, demonstration, test. Pick per requirement.
- Trace requirement → evidence, and keep the matrix where non-engineers can read it.