V-Model in Software Testing

Today, every software development organization or company has embraced the software development life cycle (SDLC) process to deliver high-quality software. It is a well-defined process for developing and delivering high-quality software products within the given deadline.

SDLC divides the task of developing software products into various phases, where each phase has its own goals and deliverables. Since the development process is divided into phases, it becomes easier for the entire development team to produce quality-standard software products.

Moreover, there are various approaches or paradigms, often called models, to carry out the SDLC process, such as the agile model, waterfall model, iterative model, incremental model, etc. Each model has its own set of practices to develop and deliver high-quality software products.

Among all, V-model is one of the popular approaches to the software development process. It is an extension of the waterfall model, where all the phases of SDLC occur in sequential order. The V-model also involves the sequential execution of all the phases of SDLC, but in a V shape.

This article intends to make you familiar with V-model.

So, let us get started!

What is V-Model?

A V-model is a type of SDLC model that executes the SDLC phases in a sequential manner in a V shape. The phases in this type of model are executed sequentially till the coding phase, and later, the remaining phases bend upwards to form a V shape.

Moreover, this model involves the testing phase in parallel with the development phase. Each development phase is associated with the corresponding testing phase. Meaning that each development activity is linked with a corresponding testing activity.

However, all the development phases take place in a sequential manner, i.e., the next phase starts only after the completion of the current phase. Hence, it is considered a highly disciplined model.

In the waterfall model, the testing phase comes after the development phase. Unlike the waterfall model, the development and testing of the software product go hand-in-hand in V-model.

V-model is also referred to as the Verification and Validation model. All the development phases fall under Verification, while the corresponding testing phases fall under Validation. So, the design of the V-model is like verification phases on the left side and validation phases on the right, both combined with the coding or implementation phase, as shown in the figure below:

Phases of V-Model

This model divides all the SDLC phases into three groups, namely the verification or development phase, coding phase, and validation or testing phase. Before proceeding to the phases, let us first understand what exactly the terms verification and validation mean.

Verification: Verification involves the static analysis technique, where testing is performed without executing the source code. It is a process of validating the software product to check whether it meets the requirements that the stakeholders specify at the onset of the development process.
Validation: Validation involves the dynamic analysis technique, where testing takes place by executing the source code. It is the process of evaluating the software product after its complete development to check whether it meets the customers’ expectations.

Verification Phase

The verification phase involves the following phases:

1. Requirements Gathering and Analysis

Requirements gathering and analysis is the first phase where the development team communicates with the customers to know what they want in the software product. The team tries to understand the requirements and expectations of the customers.

After the team gathers requirements from the customers, it conducts a brainstorming session with stakeholders to analyze those requirements. In this session, they finalize the requirements and create a software requirements specification (SRS).

Verification activities: Requirements review.
Validation activities: Creation of user-acceptance tests.
Artifacts produced: Software Requirements Specification (SRS) and user-acceptance testing.

2. System Design

Once the development team has clear and definite requirements, it moves on to develop the complete design of the system. The system design includes the entire hardware and communication setup for the software product under development. Moreover, the testing team creates the system test plan and test cases based on this system design.

Verification activities: Design review.
Validation activities: Creation of system test plan and test cases and requirements traceability matrix.
Artifacts produced: System test plan and test cases, feasibility reports, and hardware and software requirements.

3. Architecture Design

This phase involves breaking down the system design into multiple modules, where each module has different functionality. Also, it involves understanding and defining the data transfer and communication between internal modules and with the outside world, i.e., other systems.

As soon as the development team defines the above data transfer and communication information, the testing team designs and documents the integration test plan and test cases based on that information.

Verification activities: Design review.
Validation activities: Creation of integration test plan and test cases.
Artifacts produced: Integration test plan and test cases, database design tables, and design documents.

4. Module Design

In this phase, the development team defines a detailed design for each module of the system. In addition, they make sure that the design of a specific module is compatible with other modules in the system and with the external systems.

At this stage, the testing team creates unit tests for each module based on its design.

Verification activities: Design review.
Validation activities: Creation of unit test plan and test cases.
Artifacts produced: Unit test plan and test cases.

Coding Phase

Once the development team defines the design for each module of the system, it moves on to the actual implementation of each module. To begin with implementation, they decide on the programming language based on the system architecture and requirements.

Moreover, every organization has its own set of coding standards and guidelines. The development team has to follow those standards and guidelines while implementing the software product.

After the entire code is developed, it undergoes various reviews and inspections. It is optimized for the best performance and the final build of the software product is released.

Verification activities: Code review.
Validation activities: Creation of functional test cases.
Artifacts produced: Test cases and review checklist.

Validation Phases

The validation phase includes the following phases:

1. Unit Testing

Unit testing involves testing each module of the software product independently. It ensures that each unit or module of the software product functions as intended and is free from errors.

This phase is associated with the module design phase of verification. Moreover, this phase involves executing unit tests created in the module design phase on the source code to eliminate all the errors at the unit level.

Artifacts produced: Unit test cases execution results.

2. Integration Testing

After unit testing, integration testing integrates tested modules logically and tests them as a group. This type of testing ensures that there are no inconsistencies and bugs in the interaction of modules. Moreover, the integration testing phase is associated with the architecture design phase of verification.

Artifacts produced: Unit test cases execution results.

3. System Testing

System testing is associated with the system design phase. This type of testing tests the entire application, along with its functionality, interdependency, and communication with external systems. In addition, it resolves most of the hardware and software compatibility issues.

Artifacts produced: System test cases execution results, test logs, the defect report, the test summary report, and updated traceability matrix.

4. User Acceptance Testing (UAT)

User-acceptance testing (UAT) is associated with the requirements gathering and analysis phase. As its name suggests, a small group of real users performs user-acceptance testing on the software product under development to check whether it functions as expected.

Also, the testing environment of user-acceptance testing resembles the product environment. It ensures that the software product is ready to go live and meets all the requirements that customers and stakeholders specify at the beginning of the development.

Artifacts produced: UAT test cases execution results and updated business coverage metrics.

Advantages and Disadvantages of the V-Model

Let us now discuss some significant upsides and downsides of the V-model.

Advantages

The following are the remarkable upsides of the V-Model:

This SDLC model is a highly disciplined model, where each phase is completed after another.
It is ideal to adopt for small projects whose requirements are clear and definite.
It is easy to understand and implement.
This model concentrates on verification and validation at the very early stages of development, which ensures the delivery of good-quality and error-free software products.
Each phase has its own goals, deliverables, and review process. Therefore, this model is easy to manage.

Disadvantages

The following are the significant drawbacks of the V-Model:

This model is not suitable for large and complex projects.
It is not an ideal model to choose when the requirements are ambiguous and unclear.
It does not produce any working software in an intermediate stage.
This model involves high risks and uncertainty because there is no provision for risk analysis.
It does not support the iteration of phases.

When to Use the V-Model?

The following are some of the best scenarios where using the V-model would be a great choice:

The project is small or medium-sized.
Requirements are clear and well-defined.
The project definition is clear.
The tools and technologies used are not dynamic.

Difference Between V-Model and Waterfall Model

Since the V-model is an extension of the waterfall model, they share many similarities. However, there are certain differences too. The following table highlights the major differences between the two models:

V-Model	Waterfall Model
This model executes the SDLC phases in a sequential manner till the coding phase and then moves upwards to form a V-shape.	This model executes all the SDLC phases in a sequential manner.
Development and testing go hand-in-hand.	The testing phase takes place only after the development phase.
This model is more flexible than the waterfall model.	The waterfall model is rigid.
In this model, the number of defects in the software product is low.	In the waterfall model, the number of defects in the software product is higher compared to the V-model.
This model is less expensive since development and testing are simultaneous processes.	This model is expensive, as testing takes place after the development phase.

Conclusion

This brings us to the end of our discussion on the V-model. It is an SDLC model and the extension to the waterfall model, where the execution of phases takes place sequentially in a V shape. We also refer to it as the Verification and Validation model.

Moreover, the development phase and the testing phase occur concurrently. Each development phase is linked with the corresponding testing phase. Therefore, defects found in the software product are relatively lower than in the waterfall model.

We hope this article has helped you gain in-depth insights into the V-model. Still, you can post your queries in the comments section below if you have any.

People are also reading:

V-Model in Software Testing

What is V-Model?