Software Verification and Validation

Although some primitive application development processes concentrate testing and analysis at the finish of the development cycle, and the job title "tester" in some organizations still refers to a person who merely executes check cases on a complete product, today it is widely understood that execution of tests is a tiny part of the verification and validation method required to appraise and maintain the quality of a application product.

Verification and validation start as soon as we select to build a application product, or even before. In the case of Chipmunk Computers, when the Board of Governors asks the information technology (IT) manager for a feasibility study, the IT manager considers not only functionality and development costs, but also the required qualities and their impact on the overall cost.

• Verification: Have we built the software right? (i.e., does it match the specification).
• Validation: Have we built the right software? (i.e., is this what the customer wants).

The software quality manager participates with other key designers in the feasibility study, focusing in particular on risk analysis plus the measures needed to appraise plus control quality at each stage of development. The team assesses the impact of new features plus new quality requirements on the full process plus considers the contribution of quality control activities to development cost plus schedule. For example, migrating sales functions in to the Chipmunk Web-site will increase the criticality of process availability plus introduce new security issues. A feasibility study that ignored quality could lead to major unanticipated costs plus delays plus possibly to project failure.

The feasibility study inevitably involves some tentative architectural design, for example, a division of software structure corresponding to a division of responsibility between a human interface design team and groups responsible for core business software ("business logic") and supporting infrastructure, and a rough build plan breaking the project into a series of incremental deliveries. Opportunities and obstacles for costeffective verification are important considerations in factoring the development effort into subsystems and phases, and in defining major interfaces.

Architectural design splits work and separates qualities that can be verified independently in the different subsystems, thus easing the work of the testing team as well as other developers. For example, the Chipmunk design team divides the system into a presentation layer, back-end logic, and infrastructure. Development of the three subsystems is assigned to three different teams with specialized experience, each of which must meet appropriate quality constraints. The quality manager steers the early design toward a separation of concerns that will facilitate test and analysis.

In the Web presence, a clean user interface between the presentation layer and back end logic permits a corresponding division between usability testing (which is the responsibility of the human interface group, rather than the quality group) and verification of correct functioning. A clear separation of infrastructure from business logic serves a similar purpose. Responsibility for a small kernel of critical functions is allocated to specialists on the infrastructure team, leaving effectively checkable rules for consistent use of those functions throughout other parts of the system.

Taking into account quality constraints during early breakdown in to subsystems allows for a better allocation of quality requirements plus facilitates both detailed design plus testing. However, plenty of properties cannot be guaranteed by four subsystem alone. The initial breakdown of properties given in the feasibility study will be detailed during later design plus may result in "cross-quality requirements" among subsystems. For example, to guarantee a given security level, the infrastructure design team may need verification of the absence of some specific security holes (e.g., buffer overflow) in other parts of the system.