Defect repair and closure

5.3 Defect repair and closure

An important aspect of the trouble report, in whatever manner it is implemented, is that is provides a means to assure that each defect is addressed and the solution recorded. The closure of trouble reports should follow a prescribed procedure. Defects that are reported, but never resolved, can resurface at a later, and perhaps much more damaging or expensive, point in the SLC. The software quality practitioner is responsible for monitoring all open trouble reports and keeping management informed as to their status. In this way, there is less chance for a defect to escape notice and become lost. There is also a check and balance with the developers to be sure that they are not letting defects go unheeded in favor of further development activities.

The forms in Figures 5.1 and 5.2 both provide for recording the disposition of the defect. The trouble report is not considered closed until this area is filled in. Defects can get lost in the system if they are not tracked to their closure and reported as finished. Each organization should have standards that govern the reporting and tracking of defects. One of these standards should specify the length of time a defect may remain unaddressed before further activity is halted and the defect is specifically addressed. The use of on-line defect recording and status reporting can make this task quite easy and give it increased visibility.

Figure 5.2: Software change notice example.

Each trouble report, for either documentation or software in general, should provide a forward reference to the formal record of disposition of the defect and its resolution. As stated, defect reports can directly record the defect dispositions. In some organizations, there is a separate report for the disposition of a defect correction or change. One format for a separate record is the software change notice (SCN), shown in Figure 5.2. This could be used if a separate form is required to formally implement the change. In this way, the report-fix-implement-report loop is closed, and a complete trail is formed of the treatment of each reported defect.

The closure of a trouble report usually describes the action taken to correct the defect. Of course, not all trouble reports are correct themselves. There can be instances in which what was perceived as a defect was not a defect at all. Perhaps an incorrect keystroke caused a result that looked like a software defect. The trouble report still exists, however, and even though there is no change spelled out, the report must be formally closed. As a side observation, should later correlation of defect data show a high number of no-defect trouble reports, some attention may be needed on the topic of defect reporting itself.

In projects under formal CM, trouble report closures that require CM processing, especially approval of the change before implementation (see Section 6.3.2) will reflect any CM action involved. The defect tracking activity will show when the defect and its planned solution were presented for CM processing, what was done, and the results. Once CM approval has been obtained, the defect returns to the regular processing path for implementation.

Figure 5.3 depicts a typical defect reporting, tracking, and closure procedure. Each organization will have some version of this procedure that is suited to its own situation. All aspects of this procedure should be present, though. In some of the topics covered in this book, the breadth of application of the topic within a given organization of project is left up to the discretion of the organization or project. Defect reporting and tracking is a sufficiently important topic that only the actual technique used for each of the activities is seen as discretionary. The presence of a complete defect reporting and tracking system is not optional in an effective SQS.

Figure 5.3: Defect processing example.