Verification and Validation

Basketly's specification says delivery slots show in 24-hour time. The team builds exactly that, and every test against the spec passes. After release, older customers keep booking 18:00 when they meant 8 pm, and groceries arrive to empty homes. Was the feature correct? Yes and no, and two words explain the difference.

The rule

Verification: did we build it right? Validation: did we build the right thing?

Verification checks the product against its specification, at every stage. Does the design match the requirements? Does the code match the design? Does the screen match the spec? Many verification activities need no running software at all:

• reviews of requirements and designs
• code reviews and walkthroughs
• tests that compare behaviour with the written spec

Validation checks the product against the real needs of its users. The specification itself might be wrong, incomplete or misunderstood; validation catches that. Typical activities:

• user acceptance testing
• usability testing with real people
• demos and prototypes shown to customers
• watching how the feature is used after release

You need both. A product can pass verification perfectly and still fail validation, like the 24-hour slots. And a product users love can still fail verification if it breaks rules it must follow, such as tax calculations.

The shortcut

Look at what you compare against. The spec, design or standard: verification. A real person's need or goal: validation.

The trap is treating "passes all tests" as "good for users". If every test compares only with the spec, a wrong spec sails straight to production.

Drills

Answer fast — trust the rule.

Remember

• Verification: did we build it right? Validation: did we build the right thing?
• Look at what you compare against: the spec, or a real person's need.
• Passing every spec test does not prove the spec was right.