Choosing What to Report

The most dangerous part of BugzScout is the ability to include extra information with the bug report. Developers are often tempted (probably through copying other applications) to capture everything they can think of: hardware and software configuration, time of day, speed of the user's Internet connection, the versions of every DLL on the system, and even complete memory dumps.

There are two good reasons why you should resist this temptation. First, users will find such full reporting to be an invasion of their privacy, which will make them less inclined to let your software automatically report bugs (and don't even think of reporting the bugs without asking for user permission, unless you want to be branded far and wide as a spyware vendor).

Second, most of the information will be worthless in most cases. As long as you have a way to get back to the user, knowing the line of code where the crash occurred is enough information to diagnose almost any problem.

Keeping the information you send back to a minimum has another benefit: it makes the HTTP communication process faster, which means that bug reporting is less intrusive to users. And that in turn makes them more likely to report bugs.

Here are a few other tips for making good use of BugzScout:

• Rather than assign all the bugs to a single person (who might move to another project or even leave the company while your application is still in use), assign them to a virtual account with a name such as "Bugs From the Field." Project managers can search through bugs assigned to this pseudo-person and assign the important ones to actual developers.

• FogBugz identifies duplicate bug reports through their titles, so consider putting information in the title to uniquely identify the bug. You might, for example, put the product name, line number, and error number in the title, and other information in the description.

• If it looks like the bug is in your error-handling code, be suspicious. There might be something so drastically wrong elsewhere that it's thoroughly scrambling the program's state.

• Look at automatic bug reports promptly, especially during beta periods. This gives you a chance to ask users for more information while the crash is still fresh in their minds.


0 0

Post a comment