This model came up to overcome the drawback of the waterfall model. And in this model, testing starts from the requirement stage itself.

In this model, first, all the activities go on the downward direction, and at one point in time, it starts moving in the upward direction to re-use the test document for the testing process and forms a V shape. Hence it is known as the V model.

When we go for this model

We go for V and V model for the following reasons:

• For the large and complex application, here, large means that the n numbers of modules and complex specify lots of dependencies between modules.
• And It is also used for the long term projects.

Before going further in this model, first, we will understand the requirements:

Requirements

It is a document which is collected from the customer; here, we have two different types of requirements documents, which are as follows:

• CRS/BRS
• SRS/FS

CRS/BRS

The CRS or BRS stands for Customer Requirement Specification or Business Requirement Specification. For the CRS, the details will be written in the simple business (English) language by the BA (business analyst), which cannot be understood by the developers and the test engineers.

Let us see one sample example for Customer Requirement Specification to the Gmail application:

1.	Customer secured entry
2.	Optional creates mails
3.	Able to see mails
4.	Unwanted content delete
	—
	—-
15.	Successfully close the application.

SRS/ FS

It stands for Software Requirement Specifications or the Functional Specification; in this, all the details are converted to the detail document, which can be understood by the developers and the test engineers.

Let us see one sample example for Software Requirement Specifications to the Gmail application:

1.	Login ( module)
1.1	User name→ Text box (functional specification )
1.1.1	User name→ Accept only 5 alphabets
1.2	Password→ text box
1.2.1	Password→Accept only 8 characters, in which one should be capital and one special character(@,$,%,&)
1.3	OK→ Button
1.3.1	OK→ enabled
2.	Compose
2.1	To→Text Box
	—–
	—–
3.	Inbox
3.1	—-
	—-
4.	Logout

Characteristics of a functional requirement

• The requirements should be In-Details, which means it has all the details about modules, components, and the functional specification and in the Proper flow, which means that it should be in the sequence order.
• The requirements should be written in a simple language which is easy to understand by everyone.
• The requirement should be measurable or Countable.

V and V Model Process

The entire V model executes in two-phase, the complete review process is done in the verification phase, and the whole testing process is done under the validation phase; that’s why it is also known as verification and validation model.

Where the verification and validation process includes different stages:

Stage 1

It will start from collecting the CRS (customer requirement specification) document, from the client by the Business Analyst where the test engineer will check the following scenarios:

• Review the CRS based on
  • Incorrect requirements
  • Missing requirements
  • Conflicts in the requirements
• Write Acceptance Test documents

Note: In all the stages, the Test Documents includes the test plans and test cases.

Once the test engineer team reviews the CRS and found any bugs or defects, they will send it to the development team for fixing the bugs. After fixing the bugs, the development team updates the CRS and concurrently developing the SRS document.

Stage 2

After completing the CRS, the SRS is sent to the testing team for the review process, and the developers start creating the HLD (high-level design) for the application. And the testing team will test the SRS on the following scenarios:

• Review the SRS against CRS
  • Each CRS is transferred to SRS
  • CRS is not transformed properly to SRS
• Write the system Test documents

Once the testing team reviews every detail of the SRS and CRS has been converted correctly to SRS, we will move to our next stage.

Stage 3

After the completion of HLD, the developers start creating the LLD (Low-level design) for the application, and in the meantime, the tester will check the following tests on the HLD:

• Review HLD
• Write integration test documents

Stage 4

Once the testing team has done reviewing the HLD, the developers write the coding and develops the application, and the testing team will do the following tasks:

• Review the LLD
• Write functional test documents

Stage 5

After the completion of the coding part, the developers will perform one round of unit testing, which is also called white box testing, and check every line of the code and make sure that the code is correct.

After performing the unit testing, the application is sent to the testing team, where they perform multiple testing such as functional testing, integration testing, and system testing, and acceptance testing.

And once the testing part is done, the application will finally deliver to the customer.

Note:
How to handle requirement changes in V and V?
Whenever there is a change happen in the requirement, the same procedure continues, and the documents will be updated.

Advantage and Disadvantage of V and V Model

Let us see the pros and cons of the V and V model:

Advantage	disadvantage
In this, review exists in every phase, that’s why we may get less number of bugs in the application.	It is a bit expensive process because Initial investment is high as the testing team is needed from the starting stage itself.
The V model provides the Parallel deliverable, which implies that the two teams can work together like here; the development and testing team are working parallelly.	It is a time-consuming process because if requirement changes happen, we need to change every text documents.
This model helps to deliver Robust or stable products.	In this, we need to do more documentation work because of the test cases and all other documents.
In this model, the test Engineers have more knowledge about the product because testing is involved in every stage of product development.	The V model is not suitable for object-oriented projects.
The text document can be re-used.	We cannot go back and replace the functionality once the application is in the testing phase.