The Two Questions That Define Quality

In software testing, two fundamental questions shape everything we do:

  1. Are we building the product right? (Verification)
  2. Are we building the right product? (Validation)

These two questions — known as Verification and Validation, or V&V — represent two fundamentally different perspectives on quality. Understanding their distinction is essential for any tester, because confusing them leads to building polished software that nobody wants, or useful software that is full of defects.

Verification: Are We Building the Product Right?

Verification is the process of evaluating whether a product, component, or system complies with its specifications, requirements, and design documents. It checks conformance to defined rules and standards.

Think of verification as an internal quality check. You have a blueprint, and you are checking whether the construction matches that blueprint. The blueprint itself might be wrong — but that is not verification’s concern.

Verification Activities

  • Requirements reviews: Does each requirement follow the standard template? Is it testable? Are there contradictions?
  • Design reviews: Does the architecture match the requirements? Are design patterns applied correctly?
  • Code reviews: Does the code follow coding standards? Are naming conventions respected? Is error handling implemented?
  • Unit testing: Does each function return the expected output for given inputs?
  • Static analysis: Does the code have potential null pointer exceptions, memory leaks, or security vulnerabilities?
  • Walkthroughs and inspections: Do peers confirm the artifact matches its specification?

Verification Example

Requirement: “The login form must accept email addresses up to 254 characters.”

Verification checks:

  • Does the email input field accept 254 characters? (Boundary testing)
  • Does it reject 255 characters? (Boundary testing)
  • Does the database column allow 254 characters? (Schema review)
  • Does the API validate email length server-side? (Code review)
  • Does the error message appear when the limit is exceeded? (Functional testing)

All of these check whether the implementation matches the specification. None of them question whether 254 characters is the right limit or whether users even need emails that long.

Validation: Are We Building the Right Product?

Validation is the process of evaluating whether a product meets the needs and expectations of its users and stakeholders. It checks whether the software solves the actual problem it was intended to solve.

Think of validation as an external quality check. You are not comparing against a document — you are comparing against reality. Does this software actually help real people accomplish real tasks?

Validation Activities

  • User acceptance testing (UAT): Real users test the product against their actual workflows
  • Beta testing: A broader group of users evaluates the product before general release
  • Usability testing: Observing users interact with the software to identify friction points
  • A/B testing: Comparing different implementations to see which better achieves user goals
  • Prototype reviews: Users evaluate mockups before development begins
  • Stakeholder demos: Product owners confirm the delivered feature matches their vision

Validation Example

Same login form, validation perspective:

  • Do users prefer logging in with email, or would they rather use a phone number?
  • Is the “Remember me” checkbox actually useful, or do users expect to stay logged in by default?
  • Do users understand the error messages when login fails?
  • Is two-factor authentication adding security or just frustrating users who abandon the process?

These questions cannot be answered by reading a specification. They require observing real user behavior.

Comparison Table

AspectVerificationValidation
QuestionAre we building the product right?Are we building the right product?
FocusProcess and specificationsUser needs and expectations
Compares againstRequirements, design docs, standardsReal-world usage and user goals
MethodsReviews, inspections, static analysis, unit testsUAT, beta testing, usability studies
Who performsDevelopers, testers, QA teamUsers, customers, stakeholders
WhenThroughout development (shift-left)Later stages, after build (shift-right)
Can be automatedMostly yesPartially (A/B tests), mostly human judgment
FindsDefects (implementation errors)Mismatches with user expectations

The Classic Analogy

Imagine you are building a bridge:

Verification checks:

  • Are the steel beams the correct grade?
  • Is the concrete mixed to specification?
  • Are the bolts torqued to the right value?
  • Does the bridge match the engineering blueprints?

Validation checks:

  • Does the bridge actually solve the traffic problem?
  • Can the expected traffic volume cross safely?
  • Is the bridge in the right location?
  • Do drivers find it intuitive to navigate?

A bridge can pass all verification checks (built perfectly to specification) and still fail validation (built in the wrong location, solving a problem that does not exist).

How V&V Work Together

graph TD R[Requirements] --> V1[Verification: Are requirements
complete and consistent?] R --> V2[Validation: Do requirements
reflect actual user needs?] D[Design] --> V3[Verification: Does design
satisfy requirements?] D --> V4[Validation: Is the design
approach right for users?] I[Implementation] --> V5[Verification: Does code
match design?] I --> V6[Validation: Does the feature
work as users expect?] T[Delivered Product] --> V7[Verification: All specs met?] T --> V8[Validation: Users satisfied?] style V1 fill:#3b82f6,color:#fff style V3 fill:#3b82f6,color:#fff style V5 fill:#3b82f6,color:#fff style V7 fill:#3b82f6,color:#fff style V2 fill:#22c55e,color:#fff style V4 fill:#22c55e,color:#fff style V6 fill:#22c55e,color:#fff style V8 fill:#22c55e,color:#fff

Both activities happen at every phase of development, and both are necessary. A product that passes verification but fails validation is technically correct but useless. A product that passes validation but fails verification meets user needs but is unreliable.

The goal is to pass both: build the right product, and build it right.

Real-World Example

Consider a healthcare appointment scheduling system:

Verification passes, validation fails: The system perfectly implements the requirement “patients can book appointments in 15-minute slots.” All tests pass. But actual patients want to book by symptom type, and the system forces them to know which specialist they need. Patients call the reception desk instead. The software is technically perfect but practically useless.

Validation passes, verification fails: User testing shows patients love the intuitive booking interface and the symptom-based routing. But the system has a race condition: when two patients book the last slot simultaneously, both receive confirmations. The software solves the right problem but has defects.

Both pass: The system lets patients book by symptom, routes them to the correct specialist, handles concurrent bookings correctly, and patients actually use it instead of calling. This is the target.

Exercise: Classify V&V Activities

For each scenario below, determine whether it is primarily verification, validation, or both:

  1. A tester runs the automated test suite and confirms all 500 tests pass
  2. The product team watches a focus group use the new checkout flow
  3. A security auditor scans the codebase for OWASP Top 10 vulnerabilities
  4. The CEO demonstrates the product to a key enterprise client for feedback
  5. A developer runs a linter that flags non-compliant code formatting
  6. A data scientist analyzes user session recordings to find where users drop off
  7. The QA team compares the API response format against the OpenAPI specification
  8. A pilot group of 100 users tests a new feature before full rollout
HintAsk yourself: is this activity comparing against a specification/document (verification) or against user needs/expectations (validation)?
Solution
  1. Verification — Automated tests check implementation against predefined expected outcomes
  2. Validation — Focus groups evaluate whether the product meets real user needs
  3. Verification — Scanning against a defined standard (OWASP Top 10)
  4. Validation — Gathering feedback from a real stakeholder about whether the product meets their needs
  5. Verification — Checking code against a defined coding standard
  6. Validation — Analyzing real user behavior to understand if the product works for them
  7. Verification — Comparing implementation against a specification document
  8. Validation — Real users evaluating the feature in practice (beta testing)

Pro Tips

Tip 1: Requirements can be “verified” but wrong. A requirement might say “the search results page loads in under 5 seconds.” You verify this successfully. But users expect sub-1-second results because that is what Google trained them to expect. Verification passed; validation would fail. Always question the specs, not just test against them.

Tip 2: Validation is harder to automate — but not impossible. A/B testing frameworks, user analytics tools, and feature flag systems allow you to validate continuously in production. Modern QA does not wait for formal UAT sessions.

Tip 3: The best testers do both simultaneously. While testing a feature against requirements (verification), a skilled tester also thinks “would a real user actually do this?” (validation). This dual mindset catches issues that single-focused testing misses.

Key Takeaways

  • Verification checks conformance to specifications (“building the product right”)
  • Validation checks conformance to user needs (“building the right product”)
  • Both are necessary — passing one but failing the other leads to poor outcomes
  • Verification tends to be internal and document-driven; validation is external and user-driven
  • The best QA approach combines both perspectives at every development phase
  • A perfectly verified product that no one wants to use is still a failure