V Model in Software Testing | What, Why, Advantages and Disadvantages

Isn’t it frustrating to find production issues in the later stage? The waterfall model was easy to implement, but the bugs that arose in the later stage delayed the time to delivery. That is when V model in Software testing made an entry.

Here’s our overview of the V model to help you understand the What and Why of it. We also talk about the advantages and disadvantages of the V-model to help you implement the process better.

What is V Model in Software Testing?

V Model in Software testing is an SDLC model where the test execution takes place in a hierarchical manner. The execution process makes a V-shape. It is also called a Verification and Validation model that undertakes the testing process for every development phase.

For instance, if the developers roll out a new feature. Only after the testing of that new feature is over does the next phase of the V model start.

The V model in Software testing is useful for providing a systematic and visual representation of the SDLC process in a sequential manner. The shape ‘V’ represents the development and testing phase occurring together before moving on to the next stage.

Importance of Software Model:

A software project involves many development life cycles, so selecting the correct one becomes difficult. Software Development Models require careful selection by looking at the budget, team size, project criticality, and criticality of the product. Choosing the suitable model will improve the efficiency of your IT projects and manage risks associated with the software development lifecycle.

Importance of Correct Model

Looking at the PIC-1 and PIC-2 models, were you able to notice anything? Yes, you are right! PIC-1 shows mistakes in house construction, and the constructed balcony is not helpful as it is practically impossible for one can go there apart from, of course, you are a Spiderman. On the other hand, PIC-2 gives us an idea of practical, well-designed construction. It followed a proper design model before construction, whereas PIC1 has not. Hence, this needs reconstruction to make it correct.

In the case of PIC-1, the reconstruction cost is more as the issue comes into the picture late in the construction phase. We could have saved/minimized the reconstruction cost and efforts to the optimum level if a correct house model had been followed before construction or if the problem had been detected earlier in the construction phase.

The same rule applies in Software Engineering too. The necessity of correct software testing models in the Software Development Life Cycle (SDLC) is inevitable. Ideally, a Software Development Life Cycle consists of the following essential steps:

1. Planning

2. Analysis

3. Design

4. Implementation

5. Testing & Integration

6. Maintenance

Role Of Testing Process In SDLC:

Testing is an integral part of SDLC and is not a standalone activity. The software model adapted for a project will significantly impact the testing that is carried out. If testing activities do not fit into the correct development lifecycle stages, they will fail to deliver their benefit.

Every development lifecycle’s testing process has two mainly focused parts:

1. Verification

2. Validation

What is Verification?

Verification involves evaluating a work product, component, or system to determine if it meets the development requirements set. The main focus is: “Is the deliverable product built according to the specification and standards?”

What is Validation?

Validation is a process concerned with evaluating a work product, component, or system to determine if it meets the user requirements and needs. The main focus here is: “Is the deliverable product full fill its purpose and provide a solution to the customer’s problem?”

Read here – verification validation testing

Now that we understand the importance of the testing process, let’s learn about one of the software models that helps improve cost and time efficiency, enhances coordination between a team through defining proper roles for employees, and minimizes risk potential when deploying the project.

A Small Walkthrough of the Waterfall Model:

Various software models have been developed to achieve the different required objectives. These life cycles range from heavyweight methodologies to lightweight methodologies. In the Waterfall model, the software development process is in a linear sequential flow, which means that any phase in the development process begins only if the previous step is complete. Typically, the outcome of one phase acts as the input for the next phase sequentially; hence, the different SDLC phases don’t overlap.

What is the Problem with Waterfall Model?

In the Water Fall model, the testing phase tends to start late in the SDLC lifecycle, i.e. only after implementation is done. Now with this approach, it has been challenging to get feedback passed backwards and very costly if we want to change something that was not well-documented or thought upon in the previous stages.

So, What is the solution?

 As they say, “an ounce of prevention is worth a pound of cure!”. In software testing, too, the earlier in the life cycle a defect is detected, the cheaper it is to fix it. The V model was developed to tackle such problems experienced using the traditional waterfall approach. 

V Model

Also known as the verification and validation model, the V model guides where testing needs to begin as early as possible in the SDLC life cycle. Testing is not only an execution-based activity. It also involves various activities that must be covered before the end of the coding phase. V Model corresponds to both testing activities and development activities in parallel.

The following diagram illustrates the different phases in a V Model of the SDLC.

V Model of the SDLC ~ Deepti Swain

As shown above, the V Model contains Verification phases on one side and Validation phases on the other. The implementation/coding phase joins the verification and validation phases in V-shape. Thus it is called a V Model.

Now let’s deep dive into the V Model verification and validation phases.

Verification Phases of the V Model

1. User Requirements / Requirement Analysis:

Remember the example given at the beginning about house construction; before starting the construction work, an individual needs to gather specific details such as financial options, appropriate location, right contractor for constructing a house, construction and building materials, availability of water and electricity, etc.

Similarly, before starting any software project, the authorities would need to gather certain information, such as having a detailed discussion with customers to know and understand their exact requirements and expectations of the product. Analyses of the gathered requirements need to be done, then refined and come up with accurate, consistent, and unambiguous requirements, mainly in the form of documents called Requirements Specification or Requirements Definition Documents.

This document will capture both the product’s functional and non-functional requirements and the requirement’s priority. The Requirements document is signed-off formally by the stakeholders, which becomes the basis for all further activity. Based on this, the user acceptance criteria test cases are developed. The customers/stockholders, Business Analysts, and Project Managers are the key members of the requirement analysis phase.

2. System Requirements:

Once we have collected the clear and detailed product requirements, the next phase i.e., system requirements begins in earnest. Taking the Requirements Specification inputs in this phase next Functional Requirements Specification or System Requirement Specification begins.

Business Analysts and Developer Leads take the user requirements and turn those into different features that the product should have at the end. During this system requirement phase, teams will revisit and finalize the complete hardware requirements, resources, and communication setup for the product under development.

The system test plan is developed based on the system requirements phase. These requirements are segregated into different features, and features are grouped. Each feature is prioritized in this phase.

i. Global Design / High-Level Design:

The global design phase is also referred to as High-Level Design(HLD) phase. Each feature is again broken down into different modules in this phase. The Architects, Developers, Database designers, and other required members take the elements segregated in the system requirements phase as input and develop an overall high-level technical design.

This high-level design document has all the required technical details, such as hardware, software, Programming language to be used, Database design, applications touch points, etc., clearly defined. They built the HLD so that each module is associated with a specific function. This information allows integration tests to be designed and documented during this stage. 

ii. Detailed Design / Low-Level Design:

In the next stage, the Technical Specification i.e. HLD, is taken as the input. Individual developers or the team use it to develop a detailed design of their modules and their interface with other modules. Details about what type of data objects, how the data is to be collected, how the data can be integrated, business rules to be applied, and data storage are all documented in the detailed design Specification. This intricate design specification/document is also referred to as Low-Level Design. In this phase, simultaneously, unit tests can be designed on the internal low-level design of each module.

3. Implementation Phase / Coding Phase:

Programmers or Developers take the Low-Level Design Specification and start the implementation process. The coding of each module designed in the detailed design phase is taken up in the coding/implementation phase.

The coding is performed based on the coding guidelines and standards of the specific language that is being used. The developed code goes through numerous code reviews-feedbacks, and implementation and is optimized for its best performance before the final build is checked into the source repository.

Validation Phases of the V Model

As discussed earlier, every development activity will have a corresponding testing activity. And the test phase for a given level begins during the related software development activity. Now let’s discuss different validation phases in detail.

1. Component Test Execution/Unit Testing:

The component test execution phase is also referred to as component testing, unit testing, or module and program testing executed during the detailed design phases. This validation testing phase searches for defects in and verifies the functioning of software’s different modules, programs, objects, classes, etc., separately testable.

Most often, component testing stubs and drivers are used to replace the missing software and simulate the interface between the software components to achieve the testing in isolation from the rest of the system. Component testing may include different testing characteristics such as resource behavior, memory leaks, code coverage, robustness testing, etc. The detected defects are typically fixed as soon as they are found without formally recording the incidents.

Get to know here in detail about Unit Testing

2. Integration Test Execution/Integration Testing:

Primarily integration testing is carried out based on global or high-level design. The development team comes up with the technical specification and a corresponding integration for a test plan. The details are noted of how the modules or programs will be integrated, data that will be passed through the interfaces, and additional integration testing approaches such as Big Bang, Top-Down, Bottom-up, or functional incremental, etc.

Integration testing is performed to expose the defects in the interfaces between components, interactions of different parts or systems such as an Operating System and File system, etc. Here the main focus is on how other modules or components’ interaction works, not the functionality of the individual component.

Know here the key difference between Unit Testing VS Integration Testing

3. System Test Execution/ System Testing:

System testing tests an integrated system/whole system or product to verify that it meets specified requirements. The main goal is to validate that the delivery system meets the design specifications. The testing team performs complete or thorough testing in this phase, including system, functional, and non-functional test cases. Its purpose is to find as many defects as possible and report them.

System tests are generally executed in different development test environments. However, the test environments should correspond to the production environment as much as possible to minimize the risk of environment-specific bugs.

Check here out the Detailed difference between System Testing VS Integration Testing

4. Acceptance Test Execution/User Acceptance Testing:

Acceptance test execution is associated with the requirements analysis phase. Testers review the Requirement specification and check whether the requirement has enough details to be tested, there is no ambiguity if non-functional requirements are mentioned as well, whether the requirements have been prioritized, and if product risks have been captured. This Test plan is designed focused on conducting tests concerning the user needs, requirements, and business processes. 

This determines whether or not the software product/system satisfies the acceptance criteria and enables the users, customers, or other authorized entities to determine whether or not to accept the system.

Read here – User Acceptance Testing

When to use the V Model in Software Testing?

It is advisable to use the V Model on small-to-medium-sized software projects where the requirements are clear without any ambiguity. For projects where acceptance criteria are proper, V Model is the preferable choice. The V Model is useful when ample technical resources are available with technical expertise, and tech stacks and tools are not dynamic.

Principles of V Model

The principles of the V model are based on Verification and Validation, which you can find in the above sections. Here, we discuss the clear principles of the V model in Software testing:

• From Large to Small: The first principle states that the testing needs to be done in a sequential process. It must start with identifying the requirements, creating a high-level, concise design, and detailing the design phases of the project.
• Data and Process Integrity: This principle places emphasis on working with data and processes together to implement a successful project design.
• Scalability: The V model undertakes the ability to accommodate any IT project despite the size, complexity, or duration.
• Cross Reference: This principle establishes a direct correlation between requirements and corresponding testing activity.
• Clear Documentation: Like in every other project, this principle shows how documentation is a requirement that needs to be done by both the developers and the support team.

What are the Advantages of the V Model?

1. As we browse through different phases of the V Model of testing, we can conclude that this is a highly-disciplined model, and phases go one-by-one.

2. Each phase has specific deliverables and a review process, so it is easier to understand, use and manage.

3. Since the testing phases start from the beginning, ambiguities, defects, etc., are identified from the beginning; fixing those becomes more effortless and a cost-effective model.

4. Works well with smaller or medium size software projects.

What are the Disadvantages of the V Model?

1. In Today’s dynamic world, requirements changes may happen very often, whereas the V-model is a very disciplined and non-flexible model; hence, it is not suitable for projects where requirements are at a moderate to high risk of changing.

2. This model is not preferable when projects are larger or complex or have uncertain requirements and high risk.

3. Working software is produced late in the life cycle.

Conclusion

In this article – V Model in Software testing, we have discussed the importance of selecting a correct software model, how V Model is addressed to solve some of the problems experienced using the traditional waterfall approach, different verification and validation phases of V Model and where this model is preferable, and where we should avoid this.

There are numerous development life cycles involved in a software project; hence Software Development Models should be selected wisely by looking at the budget, team size, project criticality, the technology used, best practices/lessons learned, tools and techniques, quality of the developer, testers, user requirements, time, and complexity of the project. All these factors play a vital role in the success of any software project.

Frequently Asked Questions (FAQs)

What is the use of the V model?

V model is an SDLC model that helps to perform development and testing in a sequential manner. It is useful in identifying and mitigating potential flaws throughout the development process to find bugs before the final build.

What are the waterfall model and V Model?

In the waterfall model, the testing is done post the development process. In V-model, the testing is executed along with the development process.

Why is it called a V Model?

It is called a V model because the development and testing happen one after the other in a sequential manner. The V-shape represents the status of the SDLC process all the way from the requirements collection phase and analysis to design, development, testing, and support.

Is V Model agile?

V-model is not an exact agile process. It is more of an extension of the waterfall model.

Are waterfall and V Model the same?

No, the waterfall and V model are not the same. Although they both have similar processes, they differ in how they perform the testing phase after the development is over.