V – MODEL / V & V MODEL (Verification and Validation Model )

3)  V – MODEL / V & V MODEL (Verification and Validation Model )

This model came up in order to overcome the drawback of waterfall model – here testing starts from the requirement stage itself.

The V & V model is shown in the figure in the next page.

1)   In the first stage, the client send the CRS both to developers and testers. The developers translate the CRS to the SRS.

The testers do the following tests on CRS,

               1. Review CRS

                        a. conflicts in the requirements

                        b. missing requirements

                        c. wrong requirements

               2. Write Acceptance Test plan

               3. Write Acceptance Test cases

The testing team reviews the CRS and identifies mistakes and defects and send it to the development team for correcting the bugs. The development updates the CRS and continues developing SRS simultaneously.

2 ) In the next stage, the SRS is sent to the testing team for review and the developers start building the HLD of the product. The testers do the following tests on SRS,

               1.  Review SRS against CRS

                        a. every CRS is converted to SRS

                        b. CRS not converted properly to SRS

               2. Write System Test plan

               3. Write System Test case

The testing team reviews every detail of the SRS if the CRS has been converted properly to SRS.

3 ) In the next stage, the developers start building the LLD of the product. The testers do the following tests on HLD,

               1. Review HLD

               2. Write Integration test plan

               3. Write Integration test case

4 ) In the next stage, the developers start with the coding of the product. The testing team carries out the following tasks,

               1. Review LLD

               2. Write Functional test plan

               3. Write Functional Test case

After coding, the developers themselves carry out unit testing or also known as white box testing. Here the developers check each and every line of code and if the code is correct. After white-box testing, the s/w product is sent to the testing team which tests the s/w product and carries out functional testing, integration testing, system testing and acceptance testing and finally deliver the product to the client.

How to handle requirement changes in V&V:-

Whenever there is change in requirement, the same procedure continues and the documents will be updated.

Advantages of V&V model

1) Testing starts in very early stages of product development which avoids downward flow of defects which in turn reduces lot of rework

2) Testing is involved in every stage of product development

3) Deliverables are parallel/simultaneous – as developers are building SRS, testers are testing CRS and also writing ATP and ATC and so on. Thus as the developers give the finished product to testing team, the testing team is ready with all the test plans and test cases and thus the project is completed fast.

4) Total investment is less – as there is no downward flow of defects. Thus there is less or no re-work

Drawbacks of V&V model

1) Initial investment is more – because right from the beginning testing team is needed

2) More documentation work – because of the test plans and test cases and all other documents

Applications of V&V model

We go for V&V model in the following cases,

1) for long term projects

2) for complex applications

3) when customer is expecting a very high quality product within stipulated time frame because every stage is tested and developers & testing team are working in parallel