Testing, Validation & Quality Assurance

Verification vs Validation

18 min Lesson 1 of 10

Verification vs Validation

Every analyst eventually encounters a project that passes every technical test and still disappoints its users. A clinic appointment system that books appointments perfectly — but books them in UTC when every doctor works in a local time zone. An online store checkout that processes payments flawlessly — but hides the shipping cost until the very last screen, causing 40% cart abandonment. The system did exactly what the team built. It just did not do what the business actually needed.

This gap between "built correctly" and "built the right thing" is the domain of two fundamental quality concepts: verification and validation. Mastering the distinction is a prerequisite for designing meaningful tests, writing useful acceptance criteria, and earning the trust of both developers and stakeholders.

The Core Definitions

Verification asks: "Are we building the system right?" It checks that the product conforms to its specification — that what was designed is what was built. Verification activities compare the product to a document, a standard, or a model. They can be performed without involving end-users at all.

Validation asks: "Are we building the right system?" It checks that the product actually solves the real-world problem and meets stakeholder needs. Validation activities require involving real users or business representatives. A product can pass every verification check and still fail validation.

The classic formulation comes from Barry Boehm (1979): "Verification: Are we building the product right? Validation: Are we building the right product?" Memorise both questions — they will anchor every quality conversation you have throughout your career.

Consider the logistics tracking portal from earlier in the course. The team could rigorously verify that every screen matches the approved wireframes, every API call returns the correct JSON, and every database write is atomic. All verification checks pass. Then the portal goes to User Acceptance Testing — and warehouse staff immediately report that they cannot scan barcodes because the input field only accepts keyboard entry. The system was built right. It was not built right for those users. Validation catches what verification cannot.

The V-Model: Pairing Each Build Activity with a Test Activity

The V-Model (also called the Verification and Validation Model) is the canonical framework for understanding how test levels map onto development levels. The left arm of the V represents decomposition and specification activities — requirements analysis, system design, detailed design, coding. The right arm represents testing activities — unit testing, integration testing, system testing, acceptance testing. Each level on the left arm has a corresponding test level on the right arm. The arrows crossing the V represent the verification (left-arm specification) and validation (right-arm confirmation) relationship.

The V-Model: each specification level on the left arm has a corresponding test level on the right arm. Dashed horizontal arrows show the verification and validation correspondences.

Reading the V-Model

The V-Model communicates three ideas simultaneously. First, levels of abstraction: the top of the V represents the highest-level view of the system (business goals, acceptance criteria); the bottom represents the most granular view (individual code components). Second, traceability: every test level can trace its test cases back to a specific specification document on the left arm. If a unit test fails, you trace it back to a detailed design decision. If an acceptance test fails, you trace it back to a business requirement. Third, the cost of late discovery: a defect found at unit testing costs a fraction of one found at acceptance testing, because far less downstream work has been based on the wrong assumption.

The analyst's role in the V-Model: You own the top-left quadrant (writing requirements) and co-own the top-right quadrant (defining acceptance criteria). Write acceptance criteria at the same time you write each requirement — not after design has started. This is the single most effective way to shift defect discovery left.

Verification in Practice

Verification activities do not require a running system. Common verification techniques include:

Requirements reviews — structured walkthroughs of an SRS with the author, peers, and a QA analyst to catch ambiguities, contradictions, and missing constraints before development begins.
Design inspections — formal reviews of architecture or detailed design documents against the requirements they are supposed to satisfy.
Code reviews — checking that implemented logic conforms to the approved design and coding standards.
Static analysis — automated tools (linters, type-checkers, security scanners) that verify code properties without executing the code.

For an online store, a requirements review might catch a requirement that says "the system shall display the total order cost" without specifying whether that includes taxes and shipping. Caught in review, fixing the requirement takes 10 minutes. Caught after implementation, it requires reworking the cart, the order summary, the invoice template, and the payment gateway integration.

Validation in Practice

Validation requires real scenarios and real people. Common validation activities include:

User Acceptance Testing (UAT) — representative end-users execute business scenarios in a staging environment and confirm the system meets their needs.
Prototype walkthroughs — showing interactive or paper prototypes to stakeholders early in the project to confirm the proposed solution direction.
Beta testing — releasing to a controlled subset of real users to gather feedback before full launch.
Business process validation — running the new system in parallel with the old one to confirm that outputs match (or improve upon) what the business previously produced.

Common confusion — "all testing is validation": Developers frequently use "testing" to mean only verification (does the code do what I wrote?). Analysts must ensure the project plan includes genuine validation activities — scenarios written by business stakeholders, executed by real users, judged against business outcomes, not just technical correctness.

A Practical Example: Clinic Booking System

Imagine you are the analyst on a clinic appointment booking system. After requirements gathering and design, the development team builds the system. Here is how verification and validation each contribute before launch:

Verification (unit tests): The booking module correctly prevents double-booking the same doctor in overlapping time slots — matches the detailed design specification.
Verification (integration tests): The SMS reminder service correctly receives appointment data from the booking engine — matches the interface specification.
Verification (system tests): A patient can complete the full booking flow end-to-end without errors — matches the system requirements specification.
Validation (UAT): Real clinic receptionists and patients attempt typical booking scenarios. Receptionists discover that the "available slots" view does not show whether a doctor is in their main clinic or a satellite branch — a gap in the original requirements that no technical test would have caught.

Both dimensions are necessary. Verification without validation produces a technically correct system that nobody wants to use. Validation without verification produces a system that satisfies users in demos but fails unpredictably in production.

Summary

Verification confirms that the product conforms to its specification — "building the thing right."
Validation confirms that the product meets real user and business needs — "building the right thing."
The V-Model pairs each development level with a corresponding test level, from detailed design/unit testing up to business requirements/acceptance testing.
Verification activities (reviews, inspections, static analysis) can be performed without running the system and without end-user involvement.
Validation activities (UAT, prototype walkthroughs, beta testing) require real users and real business scenarios.
As an analyst, you define acceptance criteria alongside requirements — this is your primary contribution to quality assurance.