Some would say yes. I scream NOOOOOOOOO!
Severity and Priority are really two completely different concepts when it comes to managing defects. Let’s take a quick look:
Severity defines the impact that a given defect has on the system. A severe defect may cause the system to crash or invoke the dreaded blue screen of death. I don’t think anyone would argue about its severity. But how did it happen? Did it take an obscure set of key strokes or does it happen anytime the uses presses “e”? Or does it only happen only in the month of June, during sunspot activity? What about a spelling error? Or maybe the text color is a really annoying neon green. Severe? Probably not. Maybe just a cosmetic issue.
Priority, on the other hand, defines the order in which we should resolve a defect. Should we fix it now, or can it wait? How difficult is it to resolve? How many resources will be tied up by the resolution? Let’s look at our two previous examples. Issue 1 (system crash) is definitely severe, may be difficult to resolve, but only happens rarely. When should we fix it? Contrast that with the second issue (spelling error). Not severe, just makes you look bad. Should be a real easy fix. One developer, maybe 10 minutes to fix, another 10 to validate (if that). Which should get the higher Priority? Which should we fix now? I’m going to recommend fixing the typo immediately, and if there is sufficient time, fix and resolve the blue screen before the next build. I will probably wait until the next major release. It becomes….a Release Note!
Many commercial defect tracking systems have either Severity or Priority. Some may have both. Sadly, I know of only one. But others allow you to modify existing fields or add additional fields. Of course those are severely lacking in other areas. The perfect defect tracking system does not exist – yet!
Bottom-line: you need to define both Severity and Priority for your application, and based on your user’s needs. Rarely is an “out-of-the-box” solution adequate.
BTW – To solve this dilemma, I am building Dave’s Perfect Defect Tracking Tool, code-named Unicorn. Why “Unicorn” you ask? Because, like unicorns, I have heard they exist, most people can tell me what one looks like, but I’ve never seen one. Unicorn will be fully compatible with Dave’s Perfect Test Management System, code-named “Bigfoot”. Stay tuned!