It’s back to the basics folks! A classic at that – Verification Vs. Validation.
The following are some of the reasons why it is very important to understand the difference between Verification and Validation:
- It is a fundamental QA concept, therefore is almost the building block to being QA-cognizant
- It is a commonly asked interview question
- Certification syllabi (or is it syllabuses?) have a good amount of chapters revolving around this
- Finally and practically – since we testers do both – we might as well be experts at this.
Let us first start with the definitions and then we will go about understanding this with examples. Note: these definitions are as mentioned in the QAI’s CSTE CBOK (check out this link to know more about CSTE).
Verification: Verification ensures that the system (software, hardware, documentation, and personnel) complies with an organization’s standards and processes, relying on review or non-executable methods.
Validation: Validation physically ensures that the system operates according to a plan by executing the system functions through a series of tests that can be observed and evaluated.
Fair enough, right? Here come my two-cents:
When I try to deal with this concept in my class, there is a lot of confusion around it. A simple, petty example seems to solve all the confusion. It is somewhat silly but really works.
Difference between Verification and Validation with Example
Real life example: Imagine yourself going to a restaurant/diner and ordering may be blueberry pancakes. When the waiter/waitress brings your order out, how can you tell that the food that came out is as per your order?
The first things we do are look at it and notice the following things:
- Does the food look like what pancakes typically appear to be?
- Are the blueberries to be seen?
- Do they smell right?
Maybe more, but you get the gist right?
On the other hand, when you need to be absolutely sure about whether the food is as you expected: You will have to eat it.
Verification is all when you are yet to eat but are checking on few things by reviewing the subjects. Validation is when you actually eat the product to see if it is right.
In this context, I cannot help myself but go back to the CSTE CBOK reference. There is a wonderful statement out there that helps us bring this concept home.
Verification answers the question, “Did we build the right system?” while validations addresses, “Did we build the system right?”
Where Verification is Performed?
Specific to IT projects, the following are some of the areas (I must emphasize that this is not all) in which verification is performed:
|Business/Functional Requirement Review||Dev team/client for business requirements||This is a necessary step to not only make sure that the requirements have been gathered and/or correctly, but also to make sure If they are feasible or not.||Finalized requirements that are ready to be consumed by the next step – design.|
|Design Review||Dev team||Following the design creation, the Dev team reviews it thoroughly to make sure that the functional requirements can be met via the design proposed.||Design is ready to be implemented into an IT system.|
|Code Walkthrough||Individual Developer||The code once written is reviewed to identify any syntactic errors. This is more casual in nature and is performed by the individual developer on the code developed by one self.||Code ready for unit testing|
|Code Inspection||Dev team||This is a more formal set up. Subject matter experts and developers check the code to make sure it is in accordance with the business and functional goals targeted by the software.||Code ready for testing|
|Test Plan Review(internal to QA team)||QA team||Test plan is internally reviewed by the QA team to make sure that it is accurate and complete||A test plan document ready to be shared to the external teams (Project Management, Business Analysis, development, Environment, client, etc.)|
|Test Plan Review(External)||Project Manager, Business Analyst and Developer||A formal analysis of the test plan document to make sure that the timeline and other considerations of the QA team are in line with the other teams and the entire project itself.||A signed off or approved test plan document based on which the testing activity is going to be based on.|
|Test documentation review(Peer review)||QA team members||A peer review is where team members review one another's work to make sure there are no mistakes in the documentation itself.||Test documentation ready to be shared with the external teams.|
|Test documentation final review||Business Analyst and development team||A test documentation review to make sure that the test cases cover all the business conditions and functional elements of the system||Test documentation ready to be executed|
In this context, See the test documentation review article what posts a detailed process on how testers can perform the review.
Validation is all forms of testing that involves working with the product and putting it to test. Therefore, the following are all validation techniques:
Finally, the following are few things to note:
- Verification may or may not involve the product itself. Validation definitely needs the product. Verification can sometimes be performed on documents that represent the final system.
- Verification and validation do not necessarily have to be performed by testers. As you can see from the above list and table – some of these are performed by developers and other teams.
This is all there is to know about Verification and validation and to be the SMEs (Subject matter experts) on the subject.
About the author: Thanks to STH team member Swati S. for explaining the difference in simple words.
As always, we hope this has been helpful to our readers. Please let us know your comments, questions, and suggestions below.