V & V Model

Verification and Validation Model

Description

     It is a step by step or standard procedure to develop a new software. It is also called as Victory Model. In V & V Model all the stages are tested.

Why V & V Model ?

In order to overcome the drawbacks of waterfall and spiral model we go for V & V Model.
i.e. In the waterfall model requirement changes are not allowed. Both in waterfall and spiral model requirement collection and design is not tested.

Verification

 Testing/Verifying Customer Requirement Specification(CRS), Software Requirement Specification(SRS), High Level Design(HLD), Low Level Design(LLD) and check whether it is according to the customer requirement or not is called as Verification.

  1.      It is done by Test Engineer before software is developed.
  2.      Here we ensure that are we building Product Right/ System Right/ Software Right.

Validation

Testing the functionality of an application by executing test cases is called as Validation.

  1. It is done by Test Engineer once after software is developed.
  2. Here we ensure that are we building Right Product/ Right System/ Right Software.

V & V Model Image


V & V Model

Explanation

  1. Customer gives requirement in the form of CRS.
  2. Business Analyst will go to customers place and collect the CRS in business language and come back to company and explain it to project manager.
  3. Project Manager will take up the CRS and send it to both Developers and Test Engineer.
  4. Test Engineer well review CRS, write acceptance test plan and test cases.
  5. While reviewing CRS if Test Engineer find any defect (like wrong requirement  /conflicting requirement / missing requirement) then communicate defect to developer.
  6. Developer will be parallely converting CRS to SRS.
  7. Developer will open the CRS cross check weather this is defect or not.
  8. If this is a defect then developer will communicate to customer and customer will update CRS and send updated CRS to both developer and test engineer.
  9. Test Engineer will review updated CRS and also update corresponding test plan and test case, parallely developer will update defect in SRS and continue converting CRS to SRS.
  10. Once both developer and test engineer complete the work SRS is ready.
  11. Project Manager will take up the SRS and send it to both test engineer and developer.
  12. Test Engineer will review SRS against CRS and write system test plan and test case.
  13. Developer will be parallely converting SRS to HLD.
  14. Once both developer and test engineer complete the work HLD will be ready.
  15. Project Manager will take up the HLD and send it to both test engineer and developer.
  16. Test Engineer will review HLD against SRS and write integration test plan and test case.
  17. Developer will be parallely converting HLD to LLD.
  18. Once both developer and test engineer complete the work LLD will be ready.
  19. Project Manager will take up the LLD and send it to both test engineer and developer.
  20. Test Engineer will review LLD against HLD and write functional test plan and test case.
  21. Developer will be parallely writing the code by looking into SRS and LLD.
  22. Once after coding is completed developers will do white box testing.
  23. In white box testing developer will test each and every line of code.
  24. If developer find any defect developer will fix the defect again do white box testing, after white box testing is completed developer will give software to test engineer.
  25. Test Engineer will start with validation activities.
  26. First test engineer will do functional testing by executing functional test case.
  27. While doing functional testing if test engineer find any defect communicate to developer.
  28. Developer will fix the defect and do white box testing and give new software to test engineer.
  29. Test Engineer will uninstall old software, install new software, test the defect first and continue with functional testing.
  30. Test Engineer will also do integration and system testing.
  31. Once after system testing is completed test engineer / end user / customer will do acceptance testing.
  32. After acceptance testing is completed and software quality is good then software will be released to the customer.

DrawBacks

  1. Initial investment is high.
  2. Documentation is more (In every stage we should write test plan and test case).
  3. Managing interaction between developer and test engineer is very difficult.

Advantages

  1. Total time taken is less. Since testing start from early stage only.
  2. Total investment is less (Downward flow of defect will be less because of that cost of fixing defect is less).
  3. All the stages are tested (CRS, SRS, HLD and LLD).
  4. Quality of software will be good.
  5. Requirement can be change at any stage.
  6. Since Testing is done in early stage the downward flow of defect will be less because of this less reworking and less time consumption.
  7. Deliverables are parallel (It means when developer will converting CRS to SRS parallely test engineers will be reviewing CRS, write test plan and test case.

Why the model is in V shape ?

 V stands for verification and validation since both developers and test engineers works parallely so the model is in 'V' shape (It is also known as victory model).

For what kind of project we can go for v&v model ?

  1. For long term and big project.
  2. For complex project
  3. when customer wants quality software within short amount of time.

What type of defects or what mistake test engineer will find while reviewing CRS ?


Conflicting Requirement

V & V ModelMissing Requirement

V & V Model

Wrong Requirement

V & V Model

Previous
Next Post »