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
- The UI will contain 4 checkboxes labelled according to rooms they control.
- When a checkbox is checked, the signal is sent to corresponding light. A green dot appears next to the checkbox
- 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)
3
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)
2
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.
4
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
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
5