Verification vs Validation

Verification and validation (V&V) are two complementary quality assurance activities that together ensure software is both correctly built and actually useful. Though often used interchangeably in casual conversation, they address fundamentally different questions. The classic distinction, attributed to Barry Boehm, captures it perfectly: Verification asks "Are we building the product right?" while Validation asks "Are we building the right product?" Both are necessary—a system can be perfectly verified (built exactly according to specifications) yet fail validation (the specifications did not capture what users actually needed).

Understanding the Distinction

Verification checks that the software conforms to its specifications at each development stage. It ensures that the output of each phase correctly implements the input from the previous phase: code correctly implements the design, design correctly reflects the requirements, and so on. Verification is internally focused—comparing work products against their specifications.

Validation checks that the software meets the actual needs of its users and stakeholders. It ensures the final product achieves its intended purpose in its operational environment. Validation is externally focused—comparing the system against real-world expectations and needs.

A Concrete Analogy

Imagine building a bridge. Verification checks: Are the steel beams the specified thickness? Is the concrete the right grade? Are the bolts torqued to specification? Is the railing the correct height per blueprints? Validation checks: Can the bridge actually carry the traffic load it will face? Does it connect the two locations people need to travel between? Is it wide enough for the vehicles that will use it?

A bridge can pass all verification checks (built exactly to blueprints) but fail validation (the blueprints specified the wrong location, or the load calculations were wrong). Conversely, a bridge might have some verification failures (one railing slightly shorter than spec) but pass validation perfectly (it serves its purpose safely and effectively).

Verification Activities

Verification occurs throughout the development lifecycle:

Requirements Verification: Are requirements complete, consistent, unambiguous, and testable? Do they trace to business objectives? Techniques: requirement reviews, consistency analysis, completeness checks.

Design Verification: Does the design correctly address all requirements? Is the architecture sound? Are interfaces properly specified? Techniques: design reviews, formal methods, design walkthroughs.

Code Verification: Does the code correctly implement the design? Does it follow coding standards? Are there logical errors? Techniques: code reviews, static analysis, unit testing, formal inspections.

Document Verification: Does the documentation accurately describe the system? Is it consistent with the code and design? Techniques: document reviews, cross-reference checking.

Validation Activities

Validation ultimately answers: does the system solve the real problem?

Prototype Validation: Early prototypes shown to users to validate that the team's understanding of needs is correct—before investing in full implementation.

User Acceptance Testing (UAT): Actual users test the system with realistic scenarios in a production-like environment. They assess whether the system supports their workflows and meets their expectations.

Beta Testing: Releasing the system to a limited group of real users in real conditions to validate behavior under actual usage patterns.

Operational Validation: Observing the deployed system in production to confirm it delivers its intended benefits—reduced processing time, increased throughput, improved customer satisfaction.

Real-World Example: Medical Records System

A hospital commissions an electronic medical records system:

Verification activities:

• Review requirements document for completeness (all workflows covered?)
• Verify design implements all 437 documented requirements (traceability matrix)
• Verify code implements the search algorithm exactly as designed (code review)
• Verify the system returns correct results for prescribed test inputs (unit/integration testing)
• Verify response times meet the specified 2-second threshold (performance testing)

Validation activities:

• Nurses use the prototype during design phase and provide feedback: "We need to see vital signs history at a glance without clicking through three screens"
• Doctors perform UAT with sample patient records: "The allergy warning should be more prominent—I almost missed it"
• Three-month pilot in one ward reveals that the admission workflow takes longer than the paper process it replaced—the workflow needs redesign
• Post-deployment observation confirms that medication errors decreased by 40%, validating the system achieves its core objective

Notice: the system could be perfectly verified (all specs met) but still fail validation (doctors find it slower than paper). The specifications themselves were flawed—they did not adequately capture the workflow efficiency requirement.

V&V Techniques Comparison

Static vs. Dynamic V&V

Static techniques examine work products without executing the software: reviews, inspections, walkthroughs, static analysis, formal verification. These can be applied to any work product (requirements, designs, code, documentation) at any stage.

Dynamic techniques require executing the software: all forms of testing. These can only be applied once executable code exists and verify behavior through observation.

Both static and dynamic techniques serve both verification and validation purposes. A requirements review (static) can validate that requirements reflect user needs. User acceptance testing (dynamic) validates the system in operation.

The Cost of Skipping V&V

Projects that skip validation risk building the wrong system entirely—technically perfect software that nobody wants or can use. Projects that skip verification risk building a system full of defects that fails in operation despite correct intent. A balanced V&V program ensures both that the system is built correctly (verification) and that it provides real value (validation). The most expensive software failures typically result from validation failures—building exactly the wrong thing perfectly—because they require starting over rather than simply fixing defects.

Integrating V&V in Modern Development

Agile practices integrate V&V continuously rather than deferring them to separate phases. Sprint reviews with stakeholders provide ongoing validation. Automated tests provide continuous verification. Definition of done criteria combines both: code must pass all tests (verification) and the product owner must accept the story as meeting the user need (validation). This continuous approach catches both types of problems early when they are cheap to address.