Verification and Validation in Software Development

VERIFICATION AND VALIDATION IN SOFTWARE DEVELOPMENT

A. Concepts and Definitions

Software Verification and Validation (V&V) is the process of

ensuring that software being developed or changed will

satisfy functional and other requirements (validation) and

each step in the process of building the software yields the

right products (verification). The differences between

verification and validation are unimportant except to the

theorist; practitioners use the term V&V to refer to all of

the activities that are aimed at making sure the software

will function as required.

V&V is intended to be a systematic and technical evaluation

of software and associated products of the development and

maintenance processes. Reviews and tests are done at the

end of each phase of the development process to ensure

software requirements are complete and testable and that

design, code, documentation, and data satisfy those

requirements.

B. Activities

The two major V&V activities are reviews, including

inspections and walkthroughs, and testing.

1. Reviews, Inspections, and Walkthroughs

Reviews are conducted during and at the end of each phase of

the life cycle to determine whether established

requirements, design concepts, and specifications have been

met. Reviews consist of the presentation of material to a

review board or panel. Reviews are most effective when

conducted by personnel who have not been directly involved

in the development of the software being reviewed.

Informal reviews are conducted on an as-needed basis. The

developer chooses a review panel and provides and/or

presents the material to be reviewed. The material may be

as informal as a computer listing or hand-written

documentation.

Formal reviews are conducted at the end of each life cycle

phase. The acquirer of the software appoints the formal

review panel or board, who may make or affect a go/no-go

decision to proceed to the next step of the life cycle.

Formal reviews include the Software Requirements Review, the

Software Preliminary Design Review, the Software Critical

Design Review, and the Software Test Readiness Review.

An inspection or walkthrough is a detailed examination of a

product on a step-by-step or line-of-code by line-of-code

basis. The purpose of conducting inspections and

walkthroughs is to find errors. The group that does an

inspection or walkthrough is composed of peers from

development, test, and quality assurance.

2. Testing

Testing is the operation of the software with real or

simulated inputs to demonstrate that a product satisfies its

requirements and, if it does not, to identify the specific

differences between expected and actual results. There are

varied levels of software tests, ranging from unit or

element testing through integration testing and performance

testing, up to software system and acceptance tests.

a. Informal Testing

Informal tests are done by the developer to measure the

development progress. "Informal" in this case does not mean

that the tests are done in a casual manner, just that the

acquirer of the software is not formally involved, that

witnessing of the testing is not required, and that the

prime purpose of the tests is to find errors. Unit,

component, and subsystem integration tests are usually

informal tests.

Informal testing may be requirements-driven or design-

driven. Requirements-driven or black box testing is done by

selecting the input data and other parameters based on the

software requirements and observing the outputs and

reactions of the software. Black box testing can be done at

any level of integration. In addition to testing for

satisfaction of requirements, some of the objectives of

requirements-driven testing are to ascertain:

Computational correctness.

Proper handling of boundary conditions, including

extreme inputs and conditions that cause extreme outputs.

State transitioning as expected.

Proper behavior under stress or high