Manual Testing (IT)Manual Testing Specialist

What is the difference between verification and validation in manual testing? When and why to apply each of them?

Pass interviews with Hintsage AI assistant

Answer.

Verification and validation are two key concepts in testing that determine whether a product meets expectations and requirements.

Background:

In software engineering, the distinction between verification (does the product meet the specification?) and validation (does the product meet user expectations?) emerged to describe two different aspects of quality.

Problem:

Experts confuse these terms and apply approaches incorrectly: testing only according to the specifications, ignoring user experience, or vice versa, relying solely on the logic of "correct/user-friendly", forgetting formal requirements.

Solution:

  • Verification (Are we building the product right?) – checking that the product meets all specification requirements (specifications, documentation).
  • Validation (Are we building the right product?) – ensuring that the product solves the user's task and meets real expectations.
  • Use both approaches: verify against specifications, validate through "live" exploratory testing, user scenarios, acceptance tests.

Key features:

  • Verification = formal validation of requirements.
  • Validation = empathy for users, simulation of real scenarios.
  • Both stages are necessary for comprehensive error coverage.

Trick questions.

What does it mean if "the product passed verification but failed validation"?

It meets the specifications but is inconvenient, does not solve the user's task, and is not needed in the market.

Can validation start before verification?

No, the basic requirements must first be verified; otherwise, incomplete functionality won't allow the user experience to be assessed.

Does a lack of usability appear as a bug during verification?

No, this is a UX issue that can only be identified during the validation of user scenarios.

Common mistakes and anti-patterns

  • Focusing solely on specifications, ignoring UX.
  • Skipping acceptance tests.
  • Insufficient communication with those who will actually use the product.

Real-life example

Negative case

Testing was only done for compliance with documentation requirements. After launch, it turned out that users did not understand the logic of the ordering process steps, despite formal compliance with outlined cases.

Pros:

  • All specification requirements were implemented.

Cons:

  • Low user engagement, complaints, and abandonment of the product.

Positive case

An exploratory testing session was held with real users. Discovered inconveniences and improved the ordering process. Result – positive feedback, high conversion rates.

Pros:

  • The product is useful, intuitive, and in demand.

Cons:

  • More time and resources were spent on UX improvements.