How to Classify a

As in the insect world, there are bugs and BUGS! In order to assign them a proper priority, it is essential to have some means of grading them. You have to know which bugs to squash first and how many resources to throw at it. A catastrophic bug requires very different attention from a cosmetic blip. Surprisingly, to my knowledge, there isn't a universal scale. However, Table 9-2 offers a four-point classification, marked from A to D in order of decreasing severity.

Table 9-2 Bug Classification

Classification

Description

Example

Class A: Catastrophic

Crashes the program, computer, deletes executables or data.

Erases data. Aborts the program.

Class B: Serious

Data is computed incorrectly. User may be seriously misled.

Erroneous arithmetic. Program doesn't do what it should.

Class C: Malfunction

Functional may skip or does not work as it should.

Feature in specification omitted.

Class D: Superficial

Proofreading error or visual blip.

Misspelled or missing, literals or visual issue.

So Class A bugs can destroy data, programs, crash the software, or even the hardware. Programs with catastrophic Class A bugs must NEVER be released. If one is found, take immediate action to correct it.

Class B bugs generate or save invalid data. These are serious bugs and should be dealt with expediently prior to release, although they are not as life threatening as the previous classification. In practice, if you can't resolve a Class B bug, you are better off removing the feature.

Most bugs fall into Class C. They cover everything from menu options never coming into play to data appearing in an inappropriate position. While these do not derail the program, they do affect user satisfaction. Treat or release these with circumspection.

Class D or cosmetic bugs are trivial by nature and are accordingly easy to fix. Although they don't jeopardize the viability of a program, they are no credit to any manufacturer. Obvious mistakes should be corrected as speedily as possible.

Classes B-D can be further broken down into two categories: Fix now or fix later. Any bug in the fix now category must be resolved prior to any outsider testing the program. Those classified as fix later may be left until the team has the time but should be resolved before the product is launched. So within a minute you've gone from a pile of bugs in your program to having a method for recognizing them and dealing with them sensibly.

0 0

Post a comment