V-model of Testing:
In the traditional waterfall model, which is a linear or sequential model, each activity in the software development life cycle is more or less complete before the next stage begins.
The Requirements phase kicks off the project. In the Requirements phase, requirements were collected or elicited from the Customer and captured in a document called the Requirements Specification or the Requirements Definition Document or RDD for short. The document will capture the requirements, both the functional and non-functional requirements of the product. And the priority of the requirement. The Requirements document is signed-off formally by the stakeholders and this becomes the basis for all further activity. The customer, Business Analyst and Project Managers are the key members of this phase.
When the Requirements are more or less collected, the next phase begins in earnest. For this stage the Requirements Specification is the input and the output is the Functional Specification Document or the Functional Requirements Specification. BA, Developers take the Requirements Specification and turn these into different features the end product should have. The Requirements are expanded into features and features are grouped together. And again prioritized.
When the FRS is more or less complete, the next stage begins. Architects, Developers, Database designers and other take the Functional Specification and produce the Technical Specification. This document has all the required technical details – hardware, software, Programming language to be used, Database design, how the whole will be divided into different modules, each module doing a specific function.
In the next stage the Technical Specification is taken as the input. Individual developers or the team use the Technical Spec to come up with a detailed design of their individual module and its interface with other modules. Details about data to be collected, business rules to be applied and data storage are all clearly documented in the Program Specification, the output of this phase.
Programmers or Developers take the Program Specification and start the Coding process.
The V-model is an extension of the waterfall model but this time from viewpoint of testing activities that need to be completed later in SDLC.
So for every development activity there will be a corresponding testing activity. And the test phase for a given level begins during the corresponding software development activity.
- Testers become involved in reviewing documents as soon as drafts are available in the development life cycle. So during the Requirements phase, testers review the Requirement specification – checking whether the requirement has enough details to be tested, there is no ambiguity, and if non-functional requirements are mentioned as well. The tester also ensures the Requirements have been prioritized, product risks have been captured. The User Acceptance Test Plan is the outcome at the end of this phase.
- When the Functional Specification phase begins, Testers get involved, reviewing the drafts and again making sure all the features have been captured, are clear and there is enough details to test the Features. In this phase, an extra check is done – to ensure that the FRS is confirming with the Requirements Documentation. There is trace-ability to the RDD and checks are done to ensure all the Requirements have been covered in the FRS. The Functional Test Plan is the outcome of this phase.
- During the other phases downwards, which is primarily a Development Team effort, developers come up with the Technical Specification & a corresponding Integration Test Plan. The Integration Test Plan details how the modules or Programs will be integrated, data that will be passed through the interfaces and the approach to Integration – Big Bang, Top-Down or Bottom -up.
- Then the Program Specification and Unit Test plans are developed.
- The granularity and detail increases as we flow down the process.
Meanwhile, Testers review these document and use these documents to work on the next phases in the Test Process- designing Test Conditions, Test Cases, Test Environment, Test Data and are ready to go as soon as Integration testing is complete.
There are two important checking activities that we see happening above.
- The output in each phase- document or code is checked or compared with the previous documents, ensuring no Requirements has been missed or are incomplete or are different from what the RDD or the user wants. In the case of code, the code does what the user envisaged. There is a traceability backwards all the way to the RDD. These are called Validation activities – always checked against the user needs. Reviews, Unit testing, Integration testing, System testing and Acceptance testing are Validation activities. Are you building the right thing as per the user’s needs?
- The output is also checked for conformance to standards – e.g. Java Coding Standards, Website standards or benchmarks for performance, Industry Standards. This is called Verification. Is it correct, error free? These are Verification activities. Are you building it right?
