Arguing Apples and Oranges -- Explains the how Priority and Severity of the bug given
By: Elisabeth Hendrickson
Priority is Business; Severity is Technical
Tim is looking at business priority: ďHow important is it to the business that we fix the bug?Ē Jordan is looking at technical severity: ďHow nasty is the bug from a technical perspective?Ē These two questions sometimes arrive at the same answer: a high severity bug is often also high priority, but not always. Allow me to suggest some definitions.
Severity is levels:
* Critical: the software will not run
* High: unexpected fatal errors (includes crashes and data corruption)
* Medium: a feature is malfunctioning
* Low: a cosmetic issue
* Now: drop everything and take care of it as soon as you see this (usually for blocking bugs)
* P1: fix before next build to test
* P2: fix before final release
* P3: we probably wonít get to these, but we want to track them anyway
Priority is Relative; Severity is Absolute
Further, the priority might change over time. Perhaps a bug initially deemed P1 becomes rated as P2 or even a P3 as the schedule draws closer to the release and as the test team finds even more heinous errors. Priority is a subjective evaluation of how important an issue is, given other tasks in the queue and the current schedule. Itís relative. It shifts over time. And itís a business decision.
By contrast, severity is an absolute: itís an assessment of the impact of the bug without regard to other work in the queue or the current schedule. The only reason severity should change is if we have new information that causes us to re-evaluate our assessment. If it was a high severity issue when I entered it, itís still a high severity issue when itís deferred to the next release. The severity hasnít changed just because weíve run out of time. The priority changed.
Priority and Severity Donít Mix
In response to Johannaís column last week, some people suggested using both severity and priority to come up with a composite risk number. While this intuitively sounds like a way to resolve the priority-severity divide, I suggest using such an approach with extreme caution. Itís multiplying apples by oranges in an attempt to quantify bananas. Risk is yet a third type of information.
The risk associated with any bug depends on the severity of the issue, certainly. But it also depends on the likelihood that the user will run into it as well as the possible losses that might occur. I donít attempt to quantify all this when assessing the severity of an issue. In fact, I think that in most cases assessing the risk of a single issue takes more time than itís worth. Only for potentially poisonous bugs involving dangerous fixes do I really want to weigh the risk of fixing it against the risk of not fixing it.
Establish Work Precedence
The best way to avoid confusion about what comes first is to ensure everyone in the organization takes their cues for work precedence from priority and nowhere else. Developers fix P1 defects first. Testers verify P1 fixes first. Technical writers document P1 issues first. Everyone works in priority order: the priority reflects importance to the business. Saying, ďThis bug is more severe than that one so Iíll work on it firstĒ is as bad as saying, ďI like this bug more, so Iíll work on it first.Ē The severity rating is technical information used by managers as a piece of the formula in determining the priority rating. The priority rating is the final word on the order in which the work is done by programmers, testers, and everyone else.
The ultimate lesson here, regardless of the terms or levels you use to categorize your bugs, is that any classification scheme will only be effective if everyone agrees on definitions. So perhaps thatís the very first question to ask when an argument is brewing about severity, priority, or risk: ďHelp me understand exactly what information youíre using from each defect record and how youíre using it?Ē
... to read more articles, visit http://sqa.fyicenter.com/art/