With all of the advancements in defect tracking systems within the past few years, companies are still using the same ambiguous, canned fields known as Severity and Priority to categorize their defects. Let's examine a better way to assign importance to a defect.
Every software development company uses a defect tracking system. A number of vendors have been providing the software development community with useful and powerful defect tracking tools during the past few years. But are these packages being used properly? It seems that everyone uses the same data fields when defining the issue or defect, with the same types of values and the same definitions of these fields and values. But with all the changes and advancements in defect tracking systems, perhaps we need to revise the fields available and the way we categorize defect reports. Two defect tracking system fields in particular, the "severity" and "priority" fields, seem prevalent, but they allow ambiguity to slip into the process.
I have worked for several different companies and have had the opportunity to work with different tracking systems. Different tools provide varying levels of functionality in the software defect tracking process. But most of these tools have the following fields in common: Title, Description, Submitter, Owner, Subsystem, Component, Status, Resolution, ID, Priority, and Severity.
Most of these fields serve a useful purpose. The Title obviously provides a brief description of the issue that can be used in quick ticket management and review. The Description is obviously needed. Without it, the other fields lose their meaning. The Submitter allows for tracking the source of the issue, so that additional information about the defect can be obtained by development if necessary. The Owner field provides us with knowledge of who to go to for current status of the issue. Subsystem and Component help to categorize the issue and allow us to map it to a particular component of the system for use in metrics analysis of number of defects per system module. Status and Resolution are needed to allow us to determine what issues have been resolved and how they have been resolved. And of course, an ID is needed to easily order the issues and assign a unique parameter to them.
But the last two fields, Priority and Severity, seem of questionable usefulness. The tester or test manager usually fills out the Severity field when an issue is first submitted into the defect tracking system. Product management then usually fills out the priority field, following a meeting to gather information about the issue. Some may argue that these fields are the most important in the whole report, allowing a degree of impact and urgency to be associated with the description. The values for the priority and severity fields are usually High, Medium, and Low (or something similar) with the following types of definitions:
- High: A major issue where a large piece of functionality or major system component is completely broken. There is no workaround and testing cannot continue.
- Medium: A major issue where a large piece of functionality or major system component is not working properly. There is a workaround, however, and testing can continue.
- Low: A minor issue that imposes some loss of functionality, but for which there is an acceptable and easily reproducible workaround. Testing can proceed without interruption.
- High: This has a major impact on the customer. This must be fixed immediately.
- Medium: This has a major impact on the customer. The problem should be fixed before release of the current version in development, or a patch must be issued if possible.
- Low: This has a minor impact on the customer. The flaw should be fixed if there is time, but it can be deferred until the next release.
So the priority and severity fields tell us how severe an issue is to the customer, how severe it