Difference between Severity of a bug and priority of a bug:
You measure severity of a bug generally on a scale of 1 to 5 with
- 1 being “Total system crash or failure” and the QA team cannot even proceed further with their test. E.g., an e-commerce application is not even showing the login page and shows a “System unavailable”. Or maybe, system is available but after putting username and password for authentication, the application just keeps spinning the globe (IE terms) and never logs in to show the welcome page.
- 2 being “Major functionality of system not working: No workaround possible” e.g. in an e-commerce application, the credit card checkout functionality is broken. E.g., in an e-mail application like gmail, reply button is not causing the compose window to open
- 3 being “Major functionality broken but workaround possible”. This means that the QA team or the end users are able to use the application for QA or in real life but have to change their behavior to use the application. E.g, in an e-commerce application, QA team is not able to search for a product but they can navigate to the product. So, they do have a workaround for buying a certain product but this bug still needs to be fixed.
- 4 being “Minor issue”. E.g., in an e-commerce application, say the requirements said that the product page should show 5 views of the product (front view, back view, side view, top view, bottom view: e.g. this is very common for shoes, necklaces) but you found that the product page is only showing 3 views for some products. You have a feeling that this is because there are only 3 views of the product in the image catalog but you still want to open a defect just to make sure that this is not a programming error. In this case, I would give severity of 4
- 5 being “Cosmetic issue, Typos, almost a non-issue”. E.g., not a new line between paragraphs or alignment issues or maybe the programmer is from India and still writing Color as Colour and Behavior as Behaviour
Priority of a bug means how soon (how fast or how quickly) should the development team fix it. Priority is mostly measured on a scale of 1 to 5 also with 1 being fix it right now (like in the next N number of hours with N being pre-decided in the test planning phase), 2 being fix it with maybe 1-day turnaround time, 3 being fix it in say 2-3 days, 4 being fix it ASAP and 5 being fix it as time permits.
Most of the times, priority and severity would be coinciding.
However, there might be some strange cases where priority and severity are not in line.
E.g., say a QA engineer opens a defect with severity 5 because he/she found that the application does not have a legal copyright notice at the bottom. She opened it with severity 5 (low severity) because she thought this is just a cosmetic issue. But, the Project Manager might assign this priority 2 because the PM does not want to be chastised by the Legal Team. The opposite case can also happen. E.g., the QA engineer opened a bug that the customers cannot write reviews of a product. He/She gave it severity 2 (because review is major functionality and it is broken). But, the PM may give it priority 4 because perhaps PM has gotten direction from the business team that other issues/bugs facing the application are more crucial than writing reviews component.