[continued from Getting started]

Bug and feature tracking

Classification of discovered and reported bugs can be beneficial in determining priorities for development resources. High priority bugs need to be addressed as soon as reasonably possible, while suggestions should probably wait. In my experience, most companies, including Microsoft, use four or five classifications, similar to the following:

1. 1 – Severe error – This includes program crashes, errors which damage data or interfere with the operating system, or anything that prevents further testing. These types of bugs are known as “showstoppers” and, though hopefully infrequent, are urgent issues.
2. 2 – Functionality impaired – This includes any type of bug in which the program does not perform as expected and has a detrimental impact on the ability to use the program.
3. 3 – Minor issue – This includes bugs which are cosmetic, such as spelling errors, or those that do not significantly affect the ability to use the program efficiently.
4. 4 – Suggestion – This includes any suggestions for unplanned and non-essential features. These should generally be implemented only later in development, and changes to address these issues should be reflected in updated design documentation.
5. 5 – Postponed – This includes any suggestions or, in some cases, problematic bug fixes that are not likely to be in the current release, but that should nevertheless be retained for future consideration.

In parallel to the above classification of reported bugs, we also use a similar scale for prioritizing product features:

1. 1 – Essential – These are features without which the program cannot ship.
2. 2 – Important – These are features which should be in the program.
3. 3 – Desired – These are features that we want to be implemented, if possible.
4. 4 – Extra – These are features that would be nice to incorporate, if there is time.
5. 5 – Wish list – These are features that will probably have to wait for a later version.

Despite the fact that the two classification systems are similar, we generally prioritize bug fixes (levels 1-3) before implementation of new features. The only times in which a bug fix is postponed temporarily are when a feature implementation is incomplete and needs to be finished first, when an upcoming feature will obviate the bug, or when the bug is so minor that delaying the fix has no discernible adverse impact on the product.

As you begin development, it is important that you devise a method for tracking and managing both feature development and bug reports. Throughout the process, priorities invariably change and bugs will be uncovered through testing, and if you do development work for somebody else, new feature requests and change orders need to be handled. A good system will help keep the development in perspective and prevent issues from getting forgotten.

For tracking bugs and features, there are a number of software options, some of which are very expensive. Some ASP members produce reasonable software for tracking product features and bugs, so check the download site for some software designed for that purpose. I personally prefer a simple solution, so my feature and bug tracking is done with WordPad and one physical file folder. Another intriguing approach, which I learned from the member newsgroups, is to use a deck of index cards, one for each issue, and remove items physically when they have been resolved.

[continued in More to come]