This blog is dedicated to explain grooming testers - the concept and differences between Defect Severity and Priority.
Defect Severity may be defined in one word as the “IMPACT” of a defect on an application. The tester should ideally define this.
Defect Priority on the same lines, may be explained as “HOW SOON” the defect needs to be fixed. A senior developer should ideally define this after assessing the overall bugs that fall under his kitty. If possible do discuss it with Business users for which bugs they would like to have first.
These terms may appear to be simple but if you have a close look at your “Defect Tacking Tool”, validating if correct severity or priority was assigned to a defect by your team, you’ll be surprised that even senior testers would have made a mistake assessing a defect.
The following example will make this concept clear once in for all.
Be honest and try giving an example to the defect in each case. Give an example of a defect that falls in the column and write down an explanation that - why do you think it is so? Do not look at the answers until you are done with examples for each case below:
| CASE1 | CASE2 | CASE3 | CASE4 | |
| SEVERITY | HIGH | LOW | HIGH | LOW |
| PRIORITY | LOW | HIGH | HIGH | LOW |
CASE1:
For example: while testing “Yahoo Mail” software, you encountered a situation that the link that takes the user to “Address Book” module is not working. While clicking this link, a page cannot be displayed error is encountered.
Reason: Page cannot be displayed errors are generally marked with high priority. If this does not work, my testers who intend to execute and validate the “Address Book” module will sit ideal. Consequently, the scripts that involve the module will also be blocked. This certainly can be termed with “High” severity. Now this leaves you wondering, why this is termed as low priority.
If you think from a overall project perspective (end user perspective) and ask yourself a question that – Out of 10 times, how many time do you practically go to this module? – Most likely your answer will by “Not that many times”. I generally open my account to check my INBOX or COMPOSE MAIL. This in fact decides the priority. Out of your total user base (number of users), how many will actually use a particular functionality or module will decide the priority.
Needless to say, in case your test objective is to validate only the Address Book functionality then this example would certainly be a potential candidate for CASE3 section.
CASE2:
This section contains those defects that although don’t adversely affect your script execution but certainly needs to be fixed before other high severity defects. For example: while testing “Yahoo” software, you encountered a situation where the logo of the application appears “Dahoo” instead of “Yahoo”. Although not that severe, but imagine if your business user looks at this page. Certainly he will frown at you for spoiling his company logo or probably being careless at some sensitive matters. At least this spoils the first impression of the testing team and the code developed as the “First Impression is the last impression”. Worst case, he might be short tempered and take back the entire project. So this certainly takes a high priority although it has a low impact on the application.
CASE3:
The last two cases are more simple and less confusing. In case your test objective is to test a given module and a page cannot be displayed error is encountered, you tag it with a high severity and high priority
CASE4:
This includes some cosmetic defects, formatting issues, message text etc etc etc…
Hope this explanation (by now) must have cleared your concepts of DEFECT SEVERITY AND PRIORITY.
If incase you think I was able to enhance your knowledge or have any suggestions for me to improve, please leave your comments on this page.
Cheers
Anupreet Singh Bachhal
A testing novice
asbachhal@yahoo.com
