Writing Bug Reports / Defects

Spurred by: The Perfect Bug

Having read this blog entry and found it really rather interesting, it's got me thinking about Severity and Priority of defects/bug reports. What's the difference between these two mythical beasts? Two pages that google hunted out for me seem to agree that Priority is business and Severity is technical. However, the latter (the one from StickyMinds.com) argues that Severity and Priority should be abolished, which would make me happy indeed! Say, for example, you have a piece of functionality which can cause the application to crap out and save nothing done since the last save, but you know that very, very few customers use this functionality, does that make it a High Severity but a Low Priority? It seems logic that the importance of the problem to the customer is defined as "Priority" and the impact of the defect on the system is "Severity" but still, surely a unified defect classification model would make far more sense.

Which is more important to resolve? (Scale runs 1 to 3 for both Severity and Priority)

Severity 1, Priority 3 defect [ Big Technical Flaw - Low Customer Impact ]
See Above!

Severity 3, Priority 1 defect [ Small Technical Flaw - High Customer Impact ]
Maybe there's a work-around that is a massive inconvenience for the customer to use, or it slows down their use of the software, maybe making it a nightmare to use? How-about, if you navigate backwards and forwards in a wizard it doesn't persist any data, except if you navigate from start to finish....

About Rob

I've been interested in computing since the day my Dad purchased his first business PC (an Amstrad PC 1640 for anyone interested) which introduced me to MS-DOS batch programming and BASIC.

My skillset has matured somewhat since then, which you'll probably see from the posts here. You can read a bit more about me on the about page of the site, or check out some of the other posts on my areas of interest.

No Comments

Add a Comment