Chapter 3: Reviews

Overview

Reviews are the first and primary form of quality control activity. Quality control is concerned with the search for faults or defects in the various products of software development. While testing of code, as will be discussed in Chapter 4, is also concerned with the search for faults, reviews are (as has been demonstrated in countless studies) far more effective because they look for faults sooner than testing. Reviews are also more cost-effective because they consume fewer resources than do tests. They are short, require small groups of reviewers, and can be scheduled and rescheduled with minimum impact. Reviews are conducted during the process of the development, not at the end, as is the case with testing. Quality control has as its mission the detection and elimination of defects in the product. Reviews are the front line in this mission.

Reviews take place throughout the SLC and verify that the products of each phase are correct with respect to phase inputs and activities. They are sometimes referred to as precode testing. In one sense, reviews really are testing, or challenging, the product against its requirements. The only difference between testing by means of reviewing and testing by executing code is the method.

Reviews take on many forms. They may be informal peer reviews, such as one-on-one, walk-throughs, inspections, or audits. They may also be formal reviews such as verification reviews, decision-point reviews, physical or functional audits, or post-implementation reviews. Regardless of their form, the primary purpose of a review is to identify defects in the product being considered.

Boehm (see 1.5) and others have developed graphs similar to that in Figure 3.1, which show that the costs of defects rise very steeply the longer they remain in the products. Reviews are aimed at finding the defects as they are created, rather than depending on the test and operation phases to uncover them.

Figure 3.1: Costs of identified defects.

Each review has a specific purpose, objective, audience, and cast of participants. Some reviews may be held multiple times during the development, such as design walk-throughs. Others, such as the functional audit, are of such magnitude that they normally are one-time events that form the basis for major decisions about the product. In each case, however, a format and procedure for the review should be reflected in the organization's standards.

A major role of the software quality practitioner is to confirm that the reviews are scheduled as appropriate throughout the SLC and that they are held as scheduled. In some organizations, a software quality practitioner is tasked to be the chair of the review. This is up to each individual organization. It is imperative, however, that for all reviews, except perhaps very informal one-on-ones or early walk-throughs, the software quality practitioner is an active participant. The practitioner should also make sure that minutes and action items are recorded as necessary, and that any action items are suitably addressed and closed before approving and recording the review as complete. Of course, keeping management informed of the reviews and their results is imperative.

It must be noted that the entire goal of a SQS is to increase the quality of the delivered product. This, of course, entails the intentional seeking of faults and defects. It also entails an opportunity for the unskilled manager to make personnel decisions based on defects found. Some managers will be tempted to use the number of errors made by a developer as the basis for performance evaluation This is a self-defeating approach for two reasons. First, the employees may begin to react to the stress of reviews and try to minimize their defect-finding effectiveness so as to not look bad. Second, as the effectiveness of the reviews goes down, the defects being delivered to the customer will increase, which undermines the customer's confidence.