Bug Reporting

Common fundamental principles for reporting a bug:

 Report bugs as soon as possible.
The earlier you find a bug, the more time that remains in the schedule to get it fixed. Suppose
that you find an embarrassing misspelling in a Help file a few months before the software is
released. That bug has a very high likelihood of being fixed. If you find the same bug a few
hours before the release, odds are it won’t be fixed. Figure 18.1 shows this relationship
between time and bug fixing on a graph.
 This may seem strange—the bug is still the same bug whether you find it today or three
months from now. Ideally, it shouldn’t matter when it’s found, just what the bug is. In
reality, however, the risks of fixing that bug go up over time and increasingly weigh on
the decision-making process.

 Effectively describe the bugs. Suppose that you were a programmer and received the
following bug report from a tester: “Whenever I type a bunch of random characters in
the login box, the software starts to do weird stuff.” How would you even begin to fix
this bug without knowing what the random characters were, how big a bunch is, and
what kind of weird stuff was happening?
 Be nonjudgmental in reporting bugs. It’s easy for testers and programmers to form an
adversarial relationship. Bug reports can be viewed by the programmers and others on the
development team as the tester’s “report card” on their work. A bug report that says, “Your
code for controlling the printer is terrible, it just plain doesn’t work. I can’t believe that you
even checked it in for testing,” would be out of line. Bug reports should be written against the
product, not the person, and state only the facts. No gloating, no grandstanding, no
personalizing, no egos, no accusations. Tact and diplomacy are what matters.

• Follow up on your bug reports. From the moment you find a bug, it’s your responsibility to
make sure that it’s reported properly and given the attention that it needs to be addressed.
A good tester finds and logs lots of bugs. A great tester finds and logs lots of bugs but
also continues to monitor them through the process of getting them fixed

These principles—report bugs as soon as possible, effectively describe them, be

nonjudgmental in reporting them, and follow up on them—should be common sense. You
could apply these rules to almost any communications task. It’s sometimes difficult, though, in
the rush to create a product to remember to apply them to your testing. However, if you want to
be effective at reporting your bugs and getting them fixed, these are fundamental rules to
follow.
Metrics

The bug-tracking database is the perfect tool to provide this information, what its quality and
reliability level is and whether it’s on track to be ready when scheduled. This concept holds whether
you’re looking at just a small piece of the software or thousands of modules grouped together. By
following this concept, it’s easy to create metrics and graphs that can be used to get a view into the
software and determine the status of not just the test effort, but the entire project.
Three areas—the user interface, integer math, and floating-point math—make up 60 percent of
all the bugs found. If the test effort to date has been consistent across the entire product, there’s
a good chance that these three areas are indeed buggy and probably still have more bugs to
find.
This data tells you and management a great deal about the project and is a good example of
how lots of bug information can be distilled down to something simple and easily understood.
This graph is a very common one used by many teams to understand where the bugs are coming from
and if there are areas of the project that need more or less testing attention. What this
graph doesn’t show is timing information. For example, it’s possible that the bug find rate for
the user interface areas is leveling off and that the find rate for localization is increasing. This
is something you can’t tell from the graph. For that reason, another basic set of graphs is often
used that shows bugs found over time. Figure 19.7 is an example of this type of graph.

In this graph, weekly dates from June 7 through September 6 are shown on the x-axis, and the
number of bugs found each day over that period are shown on the y-axis. You can see that at
the start of the project, the bug-find rate was low and steadily increased until it became fairly
consistent at around 15 bugs per day.