I have been following verification and validation questions here with my colleagues, yet we are unable to see the slight differences, probably caused by language barrier in technical English.

An example:

  • Requirement specification

    User wants to control the lights in 4 rooms by remote command sent from the UI for each room separately.

  • Functional specification

    1. The UI will contain 4 checkboxes labelled according to rooms they control.
    2. When a checkbox is checked, the signal is sent to corresponding light. A green dot appears next to the checkbox
    3. When a checkbox is unchecked, the signal (turn off) is sent to corresponding light. A red dot appears next to the checkbox.

Let me start with what I learned here:

Verification, according to many great answers here, ensures that product reflects specified requirements - as functional spec is done by a producer based on requirements from customer, this one will be verified for completeness, correctness). Then design document will be checked against functional spec (it should design 4 checkboxes..), and the source code against design (is there a code for 4 checkboxes, functions to send the signals etc. - is it traceable to requirements).

Okay, product is built and we need to test it, validate. Here comes our understanding trouble - validation should ensure the product meets requirements for its specific intended use which is basically business requirement (does it work? can I control the lights from the UI?) but testers will definitely work with the functional spec, making sure the checkboxes are there, working, labelled, etc. They are basically checking whether the requirements in functional spec were met in the final product, isn't that verification? (should not be, lets stick to ISO 12207 that only validation is the actual testing)

  • What's the purpose of this exercise? Do you want to have a high degree of confidence in a fact that your system works to specification or do you want to make sure that your procedures comply with ISO like standards?
    – CodeART
    Oct 30, 2012 at 22:46
  • Not all testing is validation ! White box testing, for example is verific
    – user72491
    Nov 13, 2012 at 5:44
  • 1
    Generally verification means "Are we building the product right?" and validation means "Are we building the right product? Verification is the process of checking if we are doing the right things as stated in the requirements. Validation is the process of checking that we creating correct product as stated in the requirements
    – user145226
    Aug 5, 2014 at 9:25

4 Answers 4


Verification: Did we build what the customer asked for?
Validation: Does what we built work?

Edit For Clarification:

"yet testers use functional spec for their test cases"

Who cares if the testers use the functional spec they are still performing both Verification and Validation based on my original statements.

There are supposed to be three switches and two buttons on this wall. (verification)
The switches are supposed to be equi-distant apart and 48 inches off the floor (verification)
The buttons are supposed to be on either side of the switches (verification)
The left button is supposed to be labeled "Left" (verification)
The right button is supposed to be labeled "Right" (verification)
If I click the left button on, does it disable the far right switch? (validation)
If I click the left buton off, does it enable the far right switch? (validation)
If I click the right button on, does it disable the far left switch? (validation)
If I click the right button off, does it enable the far left switch? (validation)
If I click both buttons on does only the middle switch work? (validation)

  • Well, that says nothing new. What about testing, what about context of my example..Validation is actual testing but it should ensure that requirements for inteded use are met, yet testers use functional spec for their test cases..
    – John V
    Oct 30, 2012 at 18:46
  • Based on my understanding, these definitions for verification and validation are exactly the opposite of what the FDA uses for medical device regulation (fda.gov/MedicalDevices/DeviceRegulationandGuidance/…). Feb 16, 2017 at 21:05

Although verification and validation might overlap each other (yet not entirely), and might also make use of similar techniques (such as tests, walkthroughs, simulations...), they mainly differ in user involvement.

Generally, verification helps answering "Are we building the product right?". Validation, on the other hand, is trying to answer "Are we building the right product?".

So, while verification concerns requirements coverage, and if work products (not just code) meet what has been planned and designed (including standards and processes); validation ensures that products meet users expectations (that may not be exactly what is defined in requirement specification). Therefore, validation usually requires the final user involvement and production environments assessments.

Hope it can clear things out.

  • +1 In practice, often for less sensative and non-control critical software, V&V is a rubber stamping process. Verification is ensuring all the testing has been completed by the developers: functional/unit, integration, system/field, acceptance, etc. Validation is the customer saying yup, thats everything we wanted in this phase. It can be more involved, for instance when certification by a governing body like ISO is required, but that really only applies to certain segments of the industry.
    – JustinC
    Oct 30, 2012 at 16:45
  • @rvcoutinho Well, not much as the essential part is the testing itself, which is considered to be a validation even when done by testers on SIT environment. At least by ISO 12207. So in order to validate, testers need to check functional specs and make sure the program works like that.
    – John V
    Oct 30, 2012 at 17:14
  • @user970696 As said, verification and validation processes might overlap each other. And testing is a technique used in both disciplines. Yet, the goals are not exactly the same. Usually, it is a good practice to involve the final users in acceptance (validation) tests, but it is not an obligation. Acceptance tests can even be automated. In this case, a huge effort should be made not to lose the user perspective.
    – rvcoutinho
    Oct 30, 2012 at 19:12
  • 1
    @rvcoutinho This is the issue, lets follow just ISO 12207. Testing is only validation, verification are static checks.
    – John V
    Oct 30, 2012 at 19:47

The difference between verification and validation inevitably becomes ridiculously subtle when pushed. Building the right thing and building it right are inextricably joined at the hips. Our group eventually became so tired of those verification versus validation ontology wars that we banned them. We still do verification and validation, but not as distinct processes. What we do instead are inspections of various kinds (e.g., code walkthroughs), analyses of various sorts (e.g., traceability), tests (lots and lots of tests), and metrics (lots of them, too). The distinction here is fairly clear, and there are no more ontology wars.

Choose distinctions that are easy to distinguish. Verification versus validation too often are not easily distinguished.

  • +1 - and this is why august bodies such as IEEE simply refer to V&V as a combined process. Sometimes it isn't worth splitting the hairs
    – Andrew
    Nov 6, 2012 at 11:32

They are basically checking whether the requirements in functional spec were met in the final product, isn't that verification?

The verification activity is ensuring that the Functional Specification (and not forgetting the Test Specification) covers all of the requirements of the Requirement Specification - ie you haven't missed anything out, or added anything unexpected in.

The validation activity is ensuring that those requirements have been met

See also: Functional testing in the verification

  • Well the part confusing us is that "validation ensures...requirements for intended use". But testers do not check intended (high level) requirements, they simply follow functional spec (which can be invalid) to make sure everything works as described. But if its incorrectly described, then only customers validation reveal issues.
    – John V
    Oct 30, 2012 at 18:44
  • 1
    What about Unit testing? Strange as it sounds but I would say its validation.
    – John V
    Oct 30, 2012 at 19:48
  • All testing is validation (if you follow ISO12207)
    – Andrew
    Oct 30, 2012 at 20:15
  • Exactly, but how does that fit "requirements for intended use were met" definiton? This is the part I cannot get over. Unit testing does not ensure anything about requirements for intended use, it merely confirms that code works as per design/technical document.
    – John V
    Oct 30, 2012 at 20:54
  • Verification: can you map each requirement (SRS) to the design (SDS) and to its implementation in the code... Validation: does the code to what it is supposed to do
    – Andrew
    Nov 6, 2012 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.