Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing

4.2. So, What Seems to Be the Problem? The Failure Description

Bug tracking systems allow you to capture a lot of information about each bug. Some of this information is classifying data, generally selected from some set of values. For example, severity and priority ratings for bugs often run from 1 (most serious) to 5 (least serious). Other information is more narrative, describing what happens when the bug symptoms appear, how the bug was fixed, and so forth.

I'll discuss all of these possible pieces of information in detail, but let's start with the narrative data that captures the account of the problem as told by the report's author. This is the heart of any bug tracking and reporting system, the failure description. This is the message of the bug report. The failure description is the tester's first and best opportunity to communicate clearly with the programmers and the project team about a problem. Done properly, it captures in simple prose the essentials of the bug. Done poorly, it obfuscates the bug and misleads the reader.

What does a good failure description look like? Figure 4.2 shows the failure description for a nasty bug in the Speedy Writer product. The failure description contains three basic sections: summary, steps to reproduce, and isolation.

The summary is a one- or two-sentence description of the bug, emphasizing its impact on the customer or the system user. The summary tells managers, developers, and other readers why they should care about the problem. ...