Types of VandV Approaches and their Objectives and Limitations
Majority of software engineering practices attempt to create and modify software in a manner that maximizes the probability of satisfying its user expectations. As a resultant several approaches or techniques for Verification & Validation evolve across the development cycle.
Primarily V & V Techniques are of two types like:
1) Static Methods: These static methods of V&V basically involve the review processes.
2) Dynamic Methods: These dynamic methods like black box testing can be applied at all levels, even at system level. While the principle of white box testing is that it checks in for interface errors
at the module level. Black box testing can also be done at module level by testing boundary conditions and low level functions like correct displaying of error messages.
Various types of V&V approaches are categorized as under:
As the complexity and diversity of software products continue to increase, the challenge to develop new and more effective V&V strategies continues. The V&V approaches that were reasonably effective on small batch-oriented products are not sufficient for concurrent, distributed or embedded products.
The overall objective of software V&V approaches is to insure that the product is free from failures and meets its user’s expectations. Few of the theoretical and practical limitations are as under, which make this objective impossible to obtain for many products.
1) Theoretical Foundations:
Howden claims the most important theoretical result in program testing and analysis is that no general purpose testing or analysis procedure can be used to prove program correctness.
2) Impracticality of Testing all Data:
For most programs, it is impractical to attempt to test the program with all possible inputs, due to a combinational explosion. For those inputs selected, a testing oracle is needed to determine the correctness of the output for a particular test input.
3) Impracticality of Testing All Paths:
For most programs, it is impractical to attempt to test all execution paths through the project due to a combinational explosion. It is also not possible to develop an algorithm for generating test data for paths in an arbitrary product, due to the mobility to determine path feasibility.
4) No Absolute Proof of Correctness:
Howden claims that there is no such thing as an absolute proof of correctness. Instead, he suggests that there are proofs of equivalency i.e., proofs that one description of a product is equivalent to another description. Hence, unless a formal specification can be shown to be correct and, indeed, reflects exactly the user’s expectations, no claims of product correctness can be made.