According to Andrew Ratcliffe SAS Software Development with the V-Model:
Making sure it does what customers’ needs and in an appropriate way
The creation of the V-model seems to be a happy coincidence of events in the US and in Germany. Around the end of the 1980s, two separate software development teams happened upon the same fundamental idea and produced it as the V-model.
The V-model is now in wide use around the world, providing structure and focus to numerous projects.
The V-Model shows System Testing opposing the system requirements. System testing is about checking the system as a whole, not about checking the individual parts of the design. It treats the whole system as one big unit.
System testing can involve a number of specialist types of test to see if all the functional and non-functional requirements have been met. In addition to functional requirements these may include the following types of testing for the non-functional requirements:
• Performance – Are the performance criteria met?
• Volume – Can large volumes of information be handled?
• Stress – Can peak volumes of information be handled?
• Documentation – Is the documentation usable for the system?
• Robustness – Does the system remain stable under adverse circumstances?
Finally, User Acceptance Testing (UAT) is an opportunity for the customer to check that the system does what they need. It may sound like system testing but there’s a key difference: Systems testing checks that the system that was specified has been delivered, UAT checks that the system delivers what was requested. As its name implies, UAT is done by the users. The users should check that the system fits into the business processes that they choose to employ, and they should check that the documentation and training is adequate and fit for purpose.
It is not necessary to produce eight documents for each separate project (stages of the v-model).
It is quite common to deliver one document for the left-side of the V, and another for the right-side. These documents can be known as the Project Specification and the Test Specification, but names and terminology vary.
One of the most common concerns is “how much detail do I need to put into each document”. It can be answered without being clear on what the purpose of the document is. Each document typically has two purposes, i.e. to inform the next stage of verification/elucidation and to inform the associated stage of validation/testing. A third audience is the maintenance programmer (who has to fix bugs or add features six months down the line after moving to a new project, or employer, or retired). And having established those facts, the documents can be filled with the appropriate amount of detail.
The information that the V-Model framework specifies can be collected and stored in a variety of different ways and means.
Each of the stages (such as Business requirements and Design Specification) has to be a separate document. That doesn’t mean that any of this has to be typed into a Word Processor. If the code comments are prepared properly (and if coding guidelines permit) then it may not need to produce any documents for elucidation/verification.
It’s less easy to see how it can be avoided describing what intended to do for tests outside of a document, and there’s usually a demand to keep evidence of successful test runs, but each site is different so it must be judged each case on its merits.