"Are we building the product right?" is a completely different question from "are we building the right product?" — and a system can pass one while failing the other.
This is one of the most tested distinctions on the ISTQB Foundation Level exam, and for good reason — it exposes a failure mode that formal reviews alone can't catch. Verification confirms that a work product conforms to its specified requirements, design documents, or standards — it asks whether each build step matches what was specified. Validation confirms that the finished product actually fulfills the user's real need in its intended use environment — it asks whether the specification itself was the right thing to build in the first place. A system built exactly to a flawed specification can pass every verification check and still fail validation completely.
Verification, by design, only ever checks a work product against another document — code against a design spec, a design against requirements, requirements against a stakeholder's written sign-off. If that upstream document itself misunderstood what the user actually needed, every verification step downstream can pass flawlessly while producing something nobody can actually use. This is exactly why ISTQB and mature quality frameworks treat validation as a separate, mandatory activity rather than an extension of verification — validation is the only check in the process that goes back to the original, real-world need instead of to a document that was written as a proxy for that need. The classic engineering illustration is the Mars Climate Orbiter: every module reportedly passed its own internal verification (matched its own spec), yet the spacecraft was lost because one team's spec used imperial units and another's used metric — a mismatch verification within each team could never have caught, and only integrated, real-condition validation was positioned to expose.
They usually do cluster that way in a traditional V-model lifecycle, but the sequencing is not the defining distinction — the reference point being checked against is. Verification can occur late (a final code review just before release, still just checking code against spec) and validation can occur early (a prototype demoed to real users in week two of a project, well before any formal build exists, specifically to test whether the concept solves the real need before investing further). ISTQB material is explicit that these are two independent categories of activity, not two sequential project phases — a mature test strategy interleaves both throughout the lifecycle rather than running all verification first and all validation last.
Explains the ISTQB distinction between verification (does the work product conform to its specification?) and validation (does the finished product meet the real user need?), and why a system can pass every verification check while still failing validation if the underlying spec was wrong.
Both words describe "checking that something is correct," both appear constantly in quality documentation, and English usage of the two words outside engineering is nearly interchangeable — which is precisely why ISTQB dedicates specific exam content to the distinction. The reference point each check compares against is completely different: verification compares a work product to another document (its own specification); validation compares the finished product to the real-world need that specification was meant to represent.
Verification: confirmation, through the provision of objective evidence, that specified requirements have been fulfilled — commonly summarized as "are we building the product right?" Verification activities are typically static: requirements reviews, design reviews, code reviews, walkthroughs, inspections, and static analysis tools — none of them require executing the software.
Validation: confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled — summarized as "are we building the right product?" Validation activities are typically dynamic: user acceptance testing (UAT), beta testing, operational acceptance testing, and any technique that exercises the finished product against real usage conditions and real user goals.
Engineering and software quality programs that only staff verification (peer reviews, design sign-offs, code inspections) can produce a perfectly spec-compliant product that still fails in the field because the specification itself encoded a wrong assumption about the customer, the operating environment, or the regulatory requirement. This is why ISTQB-aligned test strategies, and most mature engineering V&V programs (aerospace, medical device, safety-critical software), require both a documented verification trail and a separate, independent validation activity — often involving actual end users or a customer representative — before final release or acceptance.
Yes, in principle — a team could build something that genuinely solves the user's real problem while deviating from its own written specification (perhaps the spec was outdated or the team improvised a better solution mid-build). That is still a process failure worth flagging even though the end result happens to satisfy the user, because it means the documented spec no longer matches what was actually delivered.
UAT is the most common validation technique in software projects, but validation is the broader category — it can also include beta programs, operational trials, or any activity that checks fitness for real intended use, not only a formal UAT sign-off event.
Yes — verification versus validation is explicit, examinable syllabus content in ISTQB Certified Tester Foundation Level (CTFL), typically tested with a scenario asking the candidate to identify which term applies to a described activity.
The V-model pairs each development phase on the left side (requirements, design, module design) with a corresponding test phase on the right side (acceptance test, system test, integration test) — verification activities happen throughout the left side and at each corresponding right-side phase against that phase's own spec, while validation is most concentrated at acceptance testing, where the finished system is checked against the original business need.
Try our Engineering Management, Business & Professional Skills Studio
More calculators, simulators, and guides for this discipline.
Data Analysis Studio
✨ Premium ContentA structured, paid professional training program for this discipline.