According to the V-model, each test is assumed to be executed on the actual code after it has been developed. In many cases, preliminary tests can be devised that do not require a fully developed system. Rather, they work on a “synthetic” application, one which has the same technical characteristics as the application under development, but which doesn’t really do anything of functional value. In the V-model, such tests are identified as prototypes; setting them up and running them is called prototyping. The benefit of prototyping over testing on a full system is that you can do it earlier; any correction you need to make to the specification you are prototyping will cost much less to make than if you wait until actual testing is possible.
If you create a prototype to test out some specification, it doesn’t mean that you can omit the corresponding test later on. In fact, the test is still needed, because the implementation of the specification may be incorrect. But you should be able to run the test, and especially post corrections, in much less time than if you don’t prototype.
A corollary of the view of testing that we have just described is that any deliverable created by an activity on the left side of the V-model is liable to be tested. It should therefore be couched in testable – concrete, operational – terms. A requirement that states, “The system must be extremely reliable,” is not useful. Rather, use descriptions such as, “The system must be available to users during 99% of its scheduled uptime” and “The system will produce no more than one Type 0 System Change Request per week..” The deliverable is not complete unless it also is accompanied by a test model, containing at least a description of the testing approach and ideally a set of test cases.
Another corollary is that test data have to be designed. You cannot use live data – data extracted at random from an existing application, at least not exclusively. (An exception may be made for volume testing.)
- 1283 reads
