V Model Testing – An Introduction

Having been widely adopted following its introduction, the linear waterfall system was soon found to have some limitations. A major obstacle is that testing takes place during the later stages of development, which makes it costly to rectify any identified defects. To address the situation, a modified version was introduced. The V Model demonstrates the relationship between each development activity (SDLC) and corresponding testing activity (STLC), and is also known as the verification and validation model. V model differs from waterfall in that it proceeds sequentially in a notional V shape as each part of the development process has a corresponding testing phase.

Before we move further, let’s have a brief look at the concept of verification and validation. In verification, we test documentation which includes reviews, inspections, desk checking, and walkthrough. Verification is a static technique, while validation is the actual testing of an executable code where various techniques of functional and non-functional testing are utilized.

Introduction

The V model is one of the most comprehensive ways to manage testing activities in any software project lifecycle. You will find it compared with other methods in this Short Introduction to Different SDLC Models. The objective of the V model is to improve efficiency and effectiveness by keeping development and testing activities intact.

Testing using the V Model

The beauty of using this model is that testing starts when development activities begin. In the following section, we will analyze both strands of the V model to see how they work in parallel.

• Requirement Analysis/Gathering: This is the main activity where requirements are collected and analyzed. In this phase, the focus is not on the implementation of the system but rather discovering how the system is supposed to perform or behave according to user expectations. As introduced earlier, verification and validation go hand-in-hand, and in the requirement analysis phase, the reviews come under the verification process, and the creation of UAT comes under the validation process.
• SRS: In the next step, the SRS document is reviewed by the test team. Any defects identified during the inspection, walkthrough, or desk checking, can then be rectified.
• System Design: During this phase, gathered requirements are studied for the purpose of implementation. Technical feasibility and dependency are also measured at this point. For verification purposes, testers review the design document and on the basis of this assessment, create a system test plan to enable validation.
• System Architecture: This phase is where software architecture is created. All the details of tools and technologies are finalized, to include diagrams, databases, dependencies, and so on. Documents are reviewed for verification, and an integration test plan is created by the test team for validation.
• Detailed/Module Design: Each system module is individually designed at this point. The design document is reviewed and then verified, and unit test cases prepared.
• Coding/Development: This is the phase where the actual coding is done and the system is implemented. For verification, test team perform code reviews and the functional test cases are prepared so they too can be verified.

Once the above SDLC path has been completed, the STLC cycle is executed in a sequential manner from bottom to top by employing unit testing, integration testing, system testing, and finally UAT testing. All test methods mentioned are executed in accordance with the artifacts that have been produced in the SDLC phase of the project lifecycle. At every step of STLC, the results are generated and shared with the development team for any rectification, which subsequently produces a quality software system.

The important point to note here is that QA is performed throughout the software lifecycle, and every phase should be fully documented before moving to the next, as we can see in the visual representation of V model. If the requirements are changing frequently, it is important to document them at the right time.

It is recommended that the V model is used when there is no ambiguity in the requirements and they are well defined. Also, this model is best for use on medium size projects and expert resources are available.