Victor: Why do we have two fields in a defect tracker to fill in - Severity and Priority? Are not they all the same? I have noticed that when a defect is of high severity usually it is also assigned with a top priority and vice versa. If they mean the same, why do we have 2 different names and 2 different fields in the defect tracker? Why do we need these two different parameters (severity and priority) for a defect? Can't we do only with one?
Krishna Prasad: I want to know about Priority and Severity of software bugs. Please clarify my doubt with one example of each for the following:
One afternoon at a theater:
One fine Saturday morning when Ashley (the female protagonist of my story) is still enjoying the warmth of her bed, much to her annoyance, the cell phone rings breaking the silence of the room; as if yelling to make her realize that its 8AM already and the world out side her hostel room is up and on its feet. Lazily she reaches out for her cell phone and as she looks at the screen a smile flashes across her face, even without her knowledge. It’s her BF on the phone. He asks if she can bunk her weekend MBA class and watch the noon show of the latest blockbuster in the theater near to her hostel! Ashley thinks for a moment and nods in affirmative with the typical unforgettable blushing smile flashing across her face. :) Everything seems to happen as per the plan [telling lies to her roomies, bunking the important class, reaching the multiplex in time; something that does not happen quite often :)...] until, to her horror and surprise she finds out in the theater that the person sitting behind her is none other than her own cousin who also stays in the city! Oops…
Moral of the story:
How would you describe the situation (in terms of severity)? Critical, Major, Normal, Minor... Well, assuming that Ashley’s cousin is unaware of the love story I would imagine that she would probably consider this as a Critical situation. Won’t she? Now considering that we have a critical situation (bug/defect) at hand... How fast she would want to fix this up (either by taking her cousin on a Lunch and begging her not to tell about it to anybody or by simply trying to get even with her and threaten her saying that if she opens her mouth about it she would doom her by telling about the cousin's own secret love story to others) describes the priority! The more desperate Ashley is to fix this situation up, the higher the priority! Isn't it? :)
WordWeb dictionary defines the word “Severity” as - Used of the degree of something undesirable, something hard to endure, extreme plainness. Severity of a defect/bug tells us how undesirable the defect is. For example, a bug that causes the program to crash and terminate would be considered as high severity, while a minor spelling error might be of low severity. In our organization we use a 7-point scale to rate the severity of a bug:
Blocker: This type of bug blocks development and/or testing work. Blocks users from completing the task the function was created to facilitate.
Unprioritized: The reporter has no opinion on the criticality of the issue.
WordWeb dictionary defines the word “Priority” as - Status established in order of importance or urgency. Priority of a defect/bug tells us how soon it is required to fix the problem. Priority reflects a business decision as to how soon that bug should be fixed. Priority of the bug determines what gets fixed next and what does not. The priority of a bug can be decided from either the Project management point of view or from the user’s point of view. A bug that is of high priority from the Project management point of view may or may not be of high priority if assessed from the user’s point of view. Check with your users; their prioritizations may surprise you! Priority of a bug can be classified as:
P1 – FIX the bug ASAP before the release, preferably in the current development iteration itself.
P2 – The Bug can be fixed in the successive iteration. But the fix must be done before the next major release of the Product.
Bug Severity Vs. Bug Priority:
The severity of a bug does not necessarily translate into the urgency to fix it. A severe bug that crashes the application only once on a Feb 29th (leap year) for 0.0001% of the users is lower priority than a mishandled error condition resulting in the need to re-enter a portion of the input for every user every time. Many bugs cause crashes, but aren't fixed because the crash is very infrequent or on a version/platform/feature low on the vendor's support list. Corner-case crashes, crashes that are dependent on a rare combination of sequence of events (trigger to set off the crash) fall under such classification of low priority bugs. Once I was testing the Parser of my application. And the Parser used to crash when the parameters were: 'MaxNulls' = '999999999' and 'MaxPrefixes' = '999999999'. This was a catastrophic crash, which was causing the Program to terminate. However, it took almost 2 years to get this crash fixed as it was rated with a low Priority (despite of its high severity) for obvious reason! :)
ATM Machine Example!
Let’s take the example of an ATM machine to further understand the different possible combinations of bug severity and priority:
Low Severity and High Priority Bug: Suppose you are testing an ATM machine and you notice that the welcome screen displays a misspelled Bank name! (e.g. in place of “Welcome to ICICI Bank” it rather displays “Welcome to UCICI Bank”. This is quite possible, considering the fact that the letters “U” and “I” share close neighborhood in a typical QWERTY type keyboard). This might be a cosmetic error and would not hamper the functioning of the ATM machine in any possible way; still this could prove to be a real pain in the eyes for a customer. Considering that the spelling error is in a frequently used part of the program, it might give an overall bad impression that could hurt the Bank’s reputation. These kinds of bugs are real annoyance for the customers and no Bank would want to loose revenue for a silly error like this one. So though this bug is of low severity, its priority would be high for obvious reasons. It is quite interesting that often, low severity cosmetic errors like these get a high priority.
High Severity and Low Priority Bug: Think of a bug that cause the ATM machine to black out if an user tries to use an expired ATM card and try it for 13 consecutive times (even after the machine keeps rejecting it)! Sounds like a critical crash? Well, it might be a critical bug as far as its severity is concerned, but don’t be too surprised if you see a low Priority being assigned to it. Reason? I think its obvious!
High Severity and High Priority Bug: These kinds of bugs are easier to imagine. Any kind of bug that results in some major catastrophic failure (crashes, system hang, memory corruptions, data loss, functionalities that does not work and so on) and that occurs in areas of the application that are frequently used can be classified under such types of high severity and high priority bugs. Think of scenarios where the ATM machine - does not detect a valid card even after entering correct PIN number, hangs if tried with an invalid card and/or PIN number, blocks the card after just 1 unsuccessful entry of PIN (instead of 3 wrong entries), does not dispense money even if there is sufficient cash in the a/c and in the ATM machine, dispenses incorrect amount to the user, does not forget the previous session even after the transaction is complete (in case of ATM machines where you have to swipe your card instead of inserting it), does not return the card even after the transaction is complete and so on. As you can imagine all of these cases of bugs can fall under high severity and high priority type.
Low Severity and Low Priority Bug: These are often low impact low on urgency-meter bugs that are quite harmless and can be fixed without a hurry. These kind of bugs do not harm the application in a disastrous way and the chance of an end user/customer being annoyed by it is also very less. Think of a scenario where the ATM machine does not append a title (Mr/Miss/Mrs) to the name of the customer in the welcome screen. This would not affect the business in a drastic way. And there might not be many customers who would mind it if their name is displayed without a title.
Hope I was able to make the distinction (Bug Severity Vs. Bug Priority) clear through the examples. Now here is a small testing exercise for you. Why don’t you try and present few more examples (at least one from each combination viz. high severity and low priority bugs, low severity and high priority bugs and so on) taking the ATM machine as example?