software lifecycles. Therefore testing can't begin until the end of software lifecycles. By this time all software defects have been committed. It would take more time to eliminate all of the software defects during testing than it would to finish all of the software processes before testing begins.
Most organizations don't construct and execute the structured testing techniques, documents, and levels described in the previous section. Many software projects don’t perform testing at all. And, the ones that do testing, usually resort to operational testing until software executes reasonable well, ignoring most of the latent software defect population. Defect laden software is then passed directly to customers and users.
Exhaustive software testing standards, frameworks, and techniques, tend to reduce the interest in highly structured testing, not increase it. The standards and frameworks promote the notion that a robust variety of testing techniques and structures will increase the likelihood that software defects will be eliminated. However, for software projects that don’t already do ad hoc testing very well, highly structured testing is not very high on their agenda of priorities either. While this attitude tends to be changing rapidly, testing will never be a good method for V&V.
There is some reprieve for testing enthusiasts, as streamlined testing methodologies have been created . These testing methodologies cut through the bureaucracy of encyclopedic testing standards and frameworks, identifying only the most essential and effective testing techniques. According to these testing methodologies, boundary analysis is an excellent technique for eliminating software defects. Automated test case generation for boundary analysis is now possible in many instances. However, many of these techniques would be better served by performing boundary analysis on highly structured analytical models, before software is hardcoded, not after. Furthermore, these techniques are still not the preferable V&V method. Testing still happens much too late in software lifecycles, is not holistic and in process, and would result in the necessity to eliminate inordinately large latent defect populations.
Lifecycle Frameworks (In Process)
Lifecycle frameworks are a much more progressive form of V&V than testing . Lifecycle frameworks recognize the existence and potential selection and use of multiple techniques for eliminating software defects at each software lifecycle stage. Lifecycle frameworks are referred to as in process for this reason. Lifecycle frameworks in their attempt to be thorough and holistic have evolved to be encyclopedic taxonomies of every conceivable software defect elimination technique . Lifecycle frameworks are non-methodological in the sense that each software project must tailor a new and unproven lifecycle methodology by picking and choosing from hundreds of vaguely defined and measured techniques.
More Lifecycle Framework Tasks
The IEEE Standard for Software Verification and Validation Plans  identifies thirty-one optional or additional V&V techniques that are not considered mandatory. The objective of these additional V&V techniques is to reinforce the encyclopedic nature of lifecycle frameworks, just in case something is missed. The philosophy is that more is better, and less is bad. This paper will examine an innovative notion that less is more than adequate, when it comes to V&V, and that more is unnecessary and inundating overkill. It's not necessary to enumerate the additional thirty-one V&V techniques here.
What do Lifecycle Frameworks Do?
According to the IEEE Standard Glossary of Software Engineering Terminology  V&V may be selectively defined as:
- V&V is the process of determining whether products of each development phase fulfill the requirements or conditions imposed by the previous phase.
IEEE claims that V&V frameworks provide uniform and minimum requirements for V&V. IEEE goes on to say that V&V frameworks provide for a comprehensive evaluation throughout each phase of software projects