Verification vs Validation – What’s the difference?

Understanding verification vs. validation can be confusing. Both testing processes can help improve a product’s quality, but each involves distinct goals, benefits, and challenges. It’s sometimes said that verification asks – ‘are we building the product right?’ while validation asks – ‘are we building the right product?’ While both statements are true, the full definitions are more detailed. 

To better understand the differences, let’s first have a quick look at the review process, the four levels of testing, and the differences between static and dynamic testing.

The Review Process

Reviews are an early part of the Software Testing Life Cycle (STLC) that aims to find and remove errors by verifying project-related documents. Documents to be reviewed include requirement documents, design documents, test cases, plans, and user stories. There are several types of reviews that range from something as simple as a code review to a more formal inspection. Here are a few common kinds:

• Informal Reviews – An informal review aims to obtain second opinions on any uncertainties. Informal checks can be a code or peer review, a buddy check, or even a brief conversation.
• Walkthroughs – The goal of the walkthrough is to exchange ideas about the techniques planned for developing the product. The owner of the work product typically leads a walkthrough. It facilitates group participation to discuss scenarios or consider other ways to implement the product.
• Technical Reviews – Technical reviews enable peer discussion and collective agreement on options for fixing defects. Usually led by a moderator, they involve experts who can evaluate and solve technical issues.
• Inspections – Inspections are a more formal type of review to find potential issues early in the process. Someone other than the owner of the work product leads inspections, usually a moderator. Reviewers can be other members of the team who have experience with the product.

The Four Levels of Testing

In general, there are four levels of testing: unit, integration, system, and acceptance. By testing at each level, defects can be caught earlier in the process, making them less expensive and time-consuming to resolve.

• Unit Tests – Developers generally perform unit testing. It is the process of testing individual units of code before integrating them with other parts.
• Integration Tests – After individual unit testing, the units are combined (integrated) then tested again. Integration testing can also involve examining how a third-party system interacts with a proprietary one. This takes place after unit testing and before system testing.
• System Tests – After completing integration testing, system tests are run. System testing involves evaluating the entire product (system). If a product passes all system tests, it is considered ready for the user.
• Acceptance Tests – Once development and testing are complete, a final check known as acceptance testing is performed. Acceptance testing (often called user testing) allows the stakeholder or customer to confirm the product meets their expectations.

Static and Dynamic Testing

Static testing is a process performed without executing code, even though testing code without using the code may seem unachievable. But consider work products that can be verified without using code like test plans and use cases, as mentioned in the review process section above. There’s far less chance of error when these are reviewed ahead of development. For example, if a developer uses a wrong design because no one verified its suitability, it will take more time to fix.

On the other hand, dynamic testing always involves code that has been executed in some way because this action involves inputs and analyzing the system’s output or behavior. This is done by performing unit tests, running automated scripts, or manually testing on the web application’s user interface. Dynamic testing is probably what most people think about with software testing because it validates the system under development. The four levels of testing discussed previously could equally be referred to as the ‘four levels of dynamic testing’ since they all require code that has been executed.

Now that we have a basic idea of the concepts, let’s discuss how they relate to verification vs. validation by explaining both processes.

The Verification Process

Thinking back to our original statement, ‘are we building the product right?’, we can say that the goal of verification is to evaluate the product to make sure it meets the given requirements. To do this, we must verify our documentation and plans for building the product, which we can achieve by static testing during the review process. Since verification involves checking work products and documents, it takes place before validation. In an agile operation, verification often occurs during technical or sprint planning.

Aims and Benefits

Discovering issues early helps to resolve them faster and more cheaply. Thus verification aims to find any issues before performing development work. For example, it is much more efficient to clarify acceptance criteria before development starts, rather than a developer interpreting how they think something should work, submitting the code, and then redoing their work because their interpretation differed from the clients. When done correctly, verification lessens the risk of misinterpretation. In addition, verification should make the test planning phase easier. When the tester understands the concepts and structure of the product, they can manage their time to respond to more problematic or complicated areas of code.

Challenges

Verification can come with challenges. You may find it difficult to hear if you receive criticism while in the review process. If a work item is in question, someone may need clarification, and you will have to wait for a response. And if you are writing a test plan, but the entry and acceptance criteria are missing on certain items, so might not be able to move forward with your work until you get clarification. Bottlenecks, when you are waiting for others so you can get on with your duties, can be a challenge.

The Validation Process

When we ask, ‘Are we building the right product?’ we can say that the goal of the validation process is to confirm the product will meet the customer’s needs. Validation is important because it involves testing the actual product before it is delivered to the customer or production environment. This is done by dynamic testing during each of the four levels of testing. For example, validation is done during the sprint in an agile operation as stories or bugs make their way to QA.

Aims and Benefits

Validation aims to ensure that the product works as expected. If the review process is performed correctly, each story, task, or bug should have straightforward entry, exit, and acceptance criteria. Once the tester validates the code, they can dig deeper by performing regression tests to confirm the code didn’t break other parts of the product. They can also perform destructive testing by attempting to break the code and employ other testing methods and techniques as time allows.

Challenges

Most software testers would probably say the most common challenge with validation is a lack of time for thorough testing. This can happen because when asked to estimate how long it takes to test an item, the answer can depend on several factors. If the code performs as expected, a tester could allocate more time to attempting to make it fail in other areas. If testing discovers defects, it’s common to find a cluster of defects within that section of code.

Examples of Verification and Validation

A verification tester should attend backlog refinement sessions and sprint planning meetings to listen and ask questions. This is their first opportunity to prevent defects from being introduced to the code by clarifying requirements. In addition, the tester should understand if test data needs creating, whether the new changes will affect older functions, and if they will have proper access to check the outcomes (database access, API information, etc.).

Doing thorough verification first allows the tester to validate more efficiently and thoroughly. For example, when they begin testing a story, there should be little room for questions about whether the code passes or fails.

Except for unit testing, the tester should be able to validate at each level according to the requirements of each ticket.

Conclusion

Both verification and validation processes are part of the STLC and contribute towards finding defects. In summing up, let’s have a final look at verification vs. validation. Verification is a form of static testing and part of the review process. It’s a time before development when involved parties can agree on plans to build the product by reviewing work items. It allows clarifying any ambiguity and gives the testers more understanding of the customer’s needs and expectations. In contrast, validation involves testing the product to ensure it meets the needs and expectations of the customer. It is a form of dynamic testing and can be performed through all four testing levels.