Exact Difference Between Verification and Validation with Examples
Verification vs Validation: Explore The Differences with Examples
It’s back to the basics folks! A classic look at the difference between Verification and Validation.
There is a lot of confusion and debate around these terms in the software testing world.
In this article, we will see what verification and validation are from the point of view of software testing. By the end of this article, we will get the drift of differences between the two terms.
Following are some of the important reasons to understand the difference:
- It is a fundamental QA concept, therefore it is almost the building block to being QA-cognizant.
- This is a commonly asked Software Testing Interview Question.
- Certification syllabus has a good number of chapters revolving around this.
- Finally, and practically as we testers perform both these testing types, we might as well be experts at this.
What is Verification and Validation in Software Testing?
In the context of testing, “Verification and Validation” are the two widely and commonly used terms. Most of the times, we consider both the terms as the same, but actually, these terms are quite different.
There are two aspects of V&V (Verification & Validation) tasks:
- Confirms to requirements (Producer view of quality)
- Fit for use (consumers view of quality)
Producer’s view of quality, in simpler terms, means the developers perception of the final product.
Consumers view quality means the user’s perception of the final product.
When we carry out the V&V tasks, we must concentrate on both of these views of quality.
Let us first start with the definitions of verification and validation and then we will go about understanding these terms with examples.
Note: These definitions are, as mentioned in the QAI’s CSTE CBOK (check out this link to know more about CSTE).
What is Verification?
Verification is the process of evaluating the intermediary work products of a software development lifecycle to check if we are in the right track of creating the final product.
In other words, we can also state that verification is a process to evaluate the mediator products of software to check whether the products satisfy the conditions imposed during the beginning of the phase.
Now the question here is: What are the intermediary or mediator products?
Well, these can include the documents which are produced during the development phases like, requirements specification, design documents, database table design, ER diagrams, test cases, traceability matrix, etc.
We sometimes tend to neglect the importance of reviewing these documents, but we should understand that reviewing itself can find out many hidden anomalies when if found or fixed in the later phase of the development cycle, can be very costly.
Verification ensures that the system (software, hardware, documentation, and personnel) complies with an organization’s standards and processes, relying on the review or non-executable methods.
Where is Verification Performed?
Specific to IT projects, following are some of the areas (I must emphasize that this is not all) in which verification is performed.
Verification SituationActorsDefinitionOutput
Business/Functional Requirement ReviewDev 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 ReviewDev teamFollowing 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 WalkthroughIndividual DeveloperThe 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 oneself.Code ready for unit testing.
Code InspectionDev teamThis 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 teamA 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 with 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 membersA peer review is where the team members review one another’s work to make sure that there are no mistakes in the documentation itself.Test documentation ready to be shared with the external teams.
Test documentation final reviewBusiness 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.
See the test documentation review article which posts a detailed process on how testers can perform the review.
What is Validation?
Validation is the process of evaluating the final product to check whether the software meets the business needs. In simple words, the test execution which we do in our day to day life is actually the validation activity which includes smoke testing, functional testing, regression testing, systems testing, etc.
Validation is all forms of testing that involves working with the product and putting it to test.
Given below are the validation techniques:
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 V&V 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.
Validation and Verification Examples
Real-life Example: Imagine yourself going to a restaurant/diner and ordering maybe 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 are that we 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 a 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?”
V&V in Different Phases of the Development Lifecycle
Verification and validation are performed in each of the phases of the development lifecycle.
Let’s try to have a look at them.
#1) V & V tasks – Planning
- Verification of contract.
- Evaluation of Concept document.
- Performing risk analysis.
#2) V & V tasks – Requirement phase
- Evaluation of software requirements.
- Evaluation/analysis of the interfaces.
- Generation of the systems test plan.
- Generation of Acceptance test plan.
#3) V&V tasks – Design Phase
- Evaluation of software design.
- Evaluation / Analysis of the Interfaces (UI).
- Generation of Integration test plan.
- Generation of the Component test plan.
- Generation of test design.
#4) V&V Tasks – Implementation Phase
- Evaluation of source code.
- Evaluation of documents.
- Generation of test cases.
- Generation of the test procedure.
- Execution of Components test cases.
#5) V&V Tasks – Test Phase
- Execution of systems test case.
- Execution of the acceptance test case.
- Updating traceability metrics.
- Risk analysis
#6) V&V Tasks – Installation and checkout phase
- Audit of installation and configuration.
- The final test of the installation candidate build.
- Generation of the final test report.
#7) V&V Tasks – Operation Phase
- Evaluation of new constraint.
- Assessment of the change proposed.
#8) V&V Tasks – Maintenance Phase
- Evaluation of the anomalies.
- Assessment of migration.
- Assessment of the retrial features.
- Assessment of the proposed change.
- Validating the production issues.
Difference Between Verification and Validation
VerificationValidation
Evaluates the intermediary products to check whether it meets the specific requirements of the particular phase.Evaluates the final product to check whether it meets the business needs.
Checks whether the product is built as per the specified requirement and design specification.It determines whether the software is fit for use and satisfies the business needs.
Checks “Are we building the product right”?Checks “Are we building the right product”?
This is done without executing the software.Is done with executing the software.
Involves all the static testing techniques.Includes all the dynamic testing techniques.
Examples include reviews, inspection, and walkthrough.Example includes all types of testing like smoke, regression, functional, systems and UAT.
Various Standards
ISO / IEC 12207:2008
Verification ActivitiesValidation Activities
Requirement verification involves a review of the requirements.Prepare the test requirements documents, test cases, and other test specifications to analyze the test results.
Design Verification involves reviews of all the design documents including the HLD and LDD.Evaluate that these test requirements, test cases, and other specifications reflect the requirements and is fit for use.
Code verification includes Code review.Test for boundary values, stress, and the functionalities.
Documentation Verification is the Verification of user manuals and other related documents.Test for error messages and in case of any error, the application is terminated gracefully. Tests that the software meets the business requirements and is fit for use.
CMMI:
Verification and validation are two different KPAs at maturity level 3
Verification ActivitiesValidation Activities
Performing peer reviews.Validate that the products and its components are suitable for the environment.
Verify the selected work products.When the validation process is being implemented, It is monitored and controlled.
Standardize a definite process by establishing organizational level policies for planning and doing reviews.Do lessons learned activities and collect improvement information. Institutionalize a definite process.
IEEE 1012:
The objectives of these testing activities are:
- Facilitates early detection and correction of errors.
- Encourages and enhances management intervention inside process and product risks.
- Provides supportive measures for the software lifecycle process, to enhance the compliance with schedule and budget requirements.
These are independent procedures that should be employed together to check if the system or application is in conformity with the requirements and specifications and that it achieves its intended purpose. Both are important components of the quality management system.
It is often possible that a product passes through the verification but fails in the validation phase. As it met the documented requirements & specifications, however, those specifications were themselves incapable to address the user’s needs. Thus, it is important to carry out testing for both the types to ensure the overall quality.
Verification can be used as an internal process in development, scale-up, or production. On the other hand, validation should be used as an external process to get the acceptance of fitness with stakeholders.
Is UAT Validation or Verification?
UAT (User Acceptance Testing) should be considered as validation. It is the real-world validation of the system or application, which is done by the actual users who validate if the system is “fit for use”.
Conclusion
V&V processes determine whether the products of a given activity conform to the requirements and are fit for its use.
Finally, the following are a few things to note:
- In very simpler terms (to avoid any kind of confusion), we just remember that Verification means the review activities or the static testing techniques and validation means the actual test execution activities or the dynamic testing techniques.
- Verification may or may not involve the product itself. Validation definitely needs the product. Verification can sometimes be performed on the documents that represent the final system.
- Verification and validation do not necessarily have to be performed by the testers. As you see above in this article some of these are performed by the developers and other teams.
This is all that you need to know about Verification and validation to be the SMEs (Subject matter experts) on the subject.
