Like anyone who writes software I’d love to say all my programs are entirely correct and work first time, out of the box – it’s everyone else’s software that doesn’t work, and so it’s for them that I’m going to survey bug tracking software this month.
Over the past few years, there’s been an explosion in the number of bug reporting packages – I intend to look at some of them.
First let’s generalise what’s meant by a “bug”, by removing its restriction only to actual coding: there are plenty of “software solutions” out there that weren’t produced by a group of people writing code, but by integrating several pre-written components from different providers.
Almost every application we use nowadays is a system in this sense, and that makes the bugs harder to find because they may arise not from a problem in a single component, but from the interaction between
A bug reporting system should effectively be a killing machine with a bit of reporting attachedseveral.
The problem is how to capture all the information about such bugs. For example, a user might submit a report that some feature isn’t working and we might solve the glitch for that client – that solution might prove temporary, however, and a more complete solution might require changes to several components to prevent the problem arising again in a different form.
In effect a simple bug report might end up becoming a feature request, or a collection of feature requests, and tracking these feature requests is as important as tracking the bugs that suggested them, because without this extra information some of the rationale for the changes will be lost.
Like anyone who produces software we keep different versions of a product on different systems, and a bug may be reported in one version of it, then fixed. This fix then has to be applied to the other versions, but in some cases a bug found in one version of a component is fixed in a later component because the older one is no longer supported.
Bug reports can have very complex life cycles indeed. There’s a certain irony in referring to the “lifecycle” of a bug, because of course what we really want to do is kill them. A bug reporting system should effectively be a killing machine with a bit of reporting attached.
Shrug versus smug
Bug reports come in many forms, but for the most part they’re less than helpful for diagnosing or even for describing a problem. A recent issue of the Hacker Monthly electronic magazine published a glossary of computing terms that highlighted two particular kinds of bug report that are only too familiar:
a) Shrug report: a bug report containing no error message or “how to reproduce” steps, and with only a vague description of the problem. Usually contains the phrase “doesn’t work”.
b) Smug report: a bug report submitted by a user who thinks he knows more about the system’s design than he actually does. Filled with irrelevant technical detail, plus one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it.
These humorous definitions highlight a distinction between bug reports, as the developer of a system wants them and the way bug reports are typically presented by the user.
If you have a few spare minutes take a look at the bug reporting system used by some large open-source project – once you have past the many statements telling you how to check the documentation, and then the currently open bugs, you might be able to submit your own bug.
Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.
