Categorizing Defects by Eliminating "Severity" and "Priority"

[article]

have a "High" Customer Impact. Is there any other information needed in order to categorize this issue? No. This is a high-impact issue to the customer and customer relations, and would therefore be properly scheduled by the development staff for fix before official release. In this case, the Customer Impact field has allowed the same information to be given, while replacing two fields with one, removing ambiguity from the issue, and reducing the need for a meeting to determine its priority.

Now let's look at our second example. The anomalous server crash under the severity/priority method would again have had a duality: high severity and low priority. This issue would have had a high severity because it was a server crash and caused data loss to the user, requiring the user to reboot the system. But since the user would almost never have noticed it, it had a low priority. Again we can eliminate two fields and a meeting by simply using the Customer Impact field. How does this issue, a server crash on the first full moon of every leap year, impact the customer? It won't affect the customer very much. In some cases, the customer might not even have this release of the software installed long enough on their system to even notice it. So in this case, the issue would have a low customer impact. Two fields replaced by one, and a meeting eliminated, while still providing a categorization of the issue so that it can be scheduled properly by the development team for resolution.

Conclusion
I hope this paper stimulates further review of the way defects and issues are tracked and managed during the software development lifecycle. The canned fields and definitions that seem to have proliferated in many companies should be periodically evaluated to see if there are more meaningful ways to categorize the issues properly in order to resolve them for customers. With all of the recent advances in workflow definition and reporting capabilities in defect tracking systems, this may be an opportune time for such a reevaluation. Hopefully this paper provides ideas for a good place to start to get the most out of your defect tracking system and to ease the pain of dealing with ambiguously categorized and prioritized issues.

About the author

Brian Beaver's picture Brian Beaver

Brian Beaver has worked for several software companies, ranging from startup to Fortune 500. He has performed various quality and testing related roles and has experience in refining the ways in which the defect tracker is used at several of these companies. He is also a forum moderator on qaforums.com, a software testing and quality related discussion forum with over 10,000 registered users.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03