Verification and validation
Verification and validation (V&V) are the two complementary questions every quality check answers. Verification asks “are we building the product right?” (does it meet its specification?). Validation asks “are we building the right product?” (does it actually meet the user’s needs?). Testing, reviews, and QA are the activities that answer them.
This is the process and quality view of testing: where it fits in the lifecycle and who owns it. It is deliberately separate from the engineering craft of writing the tests themselves (unit tests, TDD, AAA), which lives in the Engineering domain.
Also known as
V&V · (the pair) verification vs validation
Don't confuse with (the classic mix-ups)
- Verification vs validation. Verification = conformance to spec (build it right); validation = fitness for real use (build the right thing). A product can pass verification and fail validation: it perfectly meets a specification nobody actually wanted. Barry Boehm’s phrasing sticks: verification is “are we building the product right?”, validation is “are we building the right product?”
- QA vs QC vs testing. Quality Assurance (QA) is process-oriented and preventive (build quality in). Quality Control (QC) is product-oriented and detective (find defects in the output). Testing is a QC activity. So “the QA team” often really does QC and testing; the terms get used loosely.
- Testing as a process vs testing as a craft. This article is the process view. How to write the tests (test levels, TDD, Arrange-Act-Assert) is the engineering craft, in the Engineering domain.
- A/B testing is not this kind of testing. A/B (split) testing shows two variants to different users to see which drives better outcomes (more signups, sales, clicks). It is product experimentation, the validation idea measured empirically in the market, not a correctness check. It shares the word “testing” but answers “which is better?”, not “does it work?” (a Product and Growth topic, not QA).
Where testing sits in the lifecycle
- In waterfall, testing is a distinct phase near the end: verify and validate after the build is complete. The risk is that defects found late are the most expensive to fix.
- In agile, testing is continuous and “shift-left”: pulled as early as possible and woven into every Sprint (unit tests while coding, acceptance tests derived from acceptance criteria). See the SDLC Testing stage.
In plain English
Verification: did we build it to spec? Validation: did we build the thing people actually needed? You can do the first perfectly and still fail the second.
Who owns quality
Traditionally a separate QA department tested at the end. Modern practice pushes whole-team quality: developers write tests (TDD), the team agrees acceptance criteria up front (ATDD and BDD), and “done” only counts when it is tested (the Definition of Done).
See also
- Software development life cycle: the Testing stage this frames
- Acceptance criteria and the Definition of Done: how “verified and validated” becomes checkable
- Test-driven development, Acceptance test-driven development, Behavior-driven development: the engineering-craft side of testing
References
- B. Boehm, “Guidelines for Verifying and Validating Software Requirements and Design Specifications” (Euro IFIP 79, 1979), widely cited via the reprint “Verifying and Validating Software Requirements and Design Specifications,” IEEE Software 1(1), 1984, pp. 75–88. The source of the “building the product right / building the right product” framing. https://en.wikipedia.org/wiki/Software_verification_and_validation
- IEEE 1012, IEEE Standard for System, Software, and Hardware Verification and Validation (the 2016 edition, since superseded by the 2024 edition). https://standards.ieee.org/ieee/1012/5609/