I wanted to write about the consistently hot topic of “severity vs Priority” – which I’ve noticed that many people seem to get confused about, and that there is so much conflicting information about out there on the web.
It’s been bugging me (excuse the pun) for quite some time now. And even the great, almighty bug management system that is Jira seems to have gotten it wrong (they don’t even include a severity field by default, and the priority field seems to contain severity options…?).
My interpretation of “Severity” is how severe the bug is with regards to the system, the user and the business. So this is the impact of the bug that you find, with regards to the system. Whether it is something that has minimal impact, such as a spelling issue in a paragraph of text, or something more severe such as an application or server error screen that appears when clicking a button… The severity scale that I like to use is: Blocker, Critical, Major, Average, Minor and Trivial.
Priority on the other hand, I interpret to be the importance that the defect is fixed from the business’ perspective. So in effect, this is setting a level of importance in which the defect should be fixed purely from the context of how it affects the business. I see this as being a business decision, so testers might not necessarily set this, or they might, but with the intention of updating this after discussions/triages with the other members of the team. The scale of priority options that I like to use is: High, Medium and Low.
It’s important for us to take context into account too when thinking about a defect’s severity and priority. We have to understand the circumstances of the defect, the conditions in which the defect occurs, the frequency that it occurs, who is affected by the bug, what effects that the bug might have on the business, etc… We have to understand the defect as fully as possible before we can apply sensible severity and priority levels for it.
I’ve had many discussions on the subject of “Severity vs Priority”, and there are endless discussions/debates online on the subject. From having these discussions and getting involved in these online groups about this topic, I got thinking about how, when prioritising a defect to be fixed, we definitely need to take both the severity and priority of the defect into account when thinking about an overall prioritisation for dealing with fixing bugs… What I mean by this is that the “Priority” level (that is set based on the business effects) can’t really be the ideal scale on its own to fix bugs without taking into account the severity factor – for example, if you have multiple bugs that are a high priority, you need to additionally think about the severity of each of these bugs and also take this factor into account to determine which bugs to approach fixing first, right?
With this in mind, I had the idea of slightly modifying Eisenhower’s “Time Management Process Model”, to be relevant to “severity” and “priority”:
So, high severity and high priority items would be the main issues to attend to first. Second would be the low severity and high priority items, followed by the high severity and low priority items, and finally the low severity and low priority items.
Some examples of bugs that fit into each quadrant that spring to mind might be:
- High severity and high priority = a “server error” page appears when the “login” button is clicked on the login screen of a company’s web app – the functionality of the button is completely broken, therefore it is a severe defect. The high priority is down to the fact that users cannot log in to the web app at all, which affects the business immensely.
- Low severity and high priority = a company’s logo image doesn’t appear properly on their web application – the bug has not affect the operability of the web app in any way. It is purely a cosmetic bug, but has an urgency to be fixed due to it being the company’s logo.
- High severity and low priority = this could be a broken link that causes a “server error” page to be displayed, but the link might be on a screen that is unimportant, or the link might only be very rarely clicked by a user.
- Low severity and low priority = this might be a spelling issue that’s within a large paragraph of text that is rarely read by the users.
There are many more examples that you can find online.
One thing that I have noticed though is that context is key, and that context most likely isn’t detailed in any examples!! Even in my own examples I have not explained any details around each of my example bugs at all, and one tiny bit of detail can completely change the face of the bug which would more than likely change the severity or priority (or both).
For example, if we take the “low severity and low priority” example (the spelling issue in a large paragraph that users hardly ever read)… If this paragraph happened to be within some legislation text on the website, that is usually displayed to a user when they are required to “accept” these legal terms, then this spelling issue could be a huge problem for the business! In this context, the severity might still be low, but the priority would certainly be high.
So to sum up (before this blog post gets any longer), I believe that both “severity” and “priority” are individual aspects of a bug that should be set independently from each other (tester should set the severity and the business stakeholders should set the priority). Additionally, in order to set the severity and priority, you need to investigate the bug and gather as much information about it as possible in order to have some accuracy in the values that you set…
I believe that both of the “severity” and “priority” aspects need to be taken into account when working out a true prioritisation for fixing the defects, which is where the adaptation of Eisenhower’s “Time Management Process Model” comes in (which I hope you find useful!!).
What’s your thought on this topic?