Requirements are critical in software development and not all the requirements are of same importance.In order to determine the criticality and how timely a bug needs to get fixed is determined by these 2 factors i.e Severity and Priority. Let us take a look and define these terms.
UNDERSTANDING SEVERITY
Severity of the bug refers to the measure of how important the bug is for the system or the end user.Basically how badly it affects the software being developed,how difficult it can get if the bug doesn’t gets fixed. There can be complex rules around determining the severity of the issue based upon the reproducible rate,the probability of user coming across the issue and how easily the impact can be nullified by switching to any workarounds (if available). Severity can be a danger to the health of the software or the system. It varies with the extent of crashing the system or a security breach or to any functionality that is not working or is missing.

Bug severity can be categorized into four classes

• CRITICAL – This is a state when we have a complete shutdown , crash or a showstopper in the system. A piece that prevents further testing of the product or a function under test.In general, no workaround is possible for such bugs. Example of this can be a missing menu option to access a functionality under test.
• HIGH – This class of severity refers to a bug that does not function as expected/designed or which can cause other functionality to fail and the meet requirements. The workaround or alternatives can be provided for such bugs. Example of this include inaccurate login/calculations.
• MEDIUM – The category bugs are mostly which do not conform to standards and conventions or match the product requirements. They are pretty direct and easy workarounds exists to achieve the objectives. Example include matching the visual and text links as per the requirements document.
• LOW – Cosmetic bugs which does not affect the functionality of the system can be classified as Low severity bugs. Example includes spelling mistakes,minor UI distortions.

HOW DO WE DEFINE PRIORITY?
Bug Priority tells us how soon it is desired to fix the problem. Priority is the importance of bug in terms of customer’s requirements.It is set by the Business / Development Lead for the Development team to prioritise in fixing the bugs.When a bug is of high severity, most likely it will also have a high priority. Likewise, a low severity bug will normally have a low priority as well. Though it as also possible that a high severity bug can have a low priority, and vice versa. Example after printing 10,000 records system crashes. Now in this priroty is low but severity is high. Whereas, let us say the logo of the company appearing on the site is wrong. This is a high priority issue, but severity is low.

We generally determine priority by considering the following :-

1. Business need to fix the bug.
2. Impact or the severity over the product.
3. Occurrence,probability or visibility of the bug in the system.
4. Available time and resources to fix the bug.
5. Levels of priority of bugs

• Priority 1 – Critical (P1) : This is a “Must-now” condition as the bug must be resolved as soon as possible as it affects the system severely and it cannot be used until this one is fixed.It generally happens when the functionality is missing or broken and henceforth the testing is completely blocked.Sometimes it is also due to memory leaks or system network issues.Example of P1 issue can be the complete site shutdown.
• Priority 2 – High (P2) : This is a “Must-have”. Once the P1 bug have been fixed, a bug having this priority is the next which needs to be fixed for any test activity to complete. Generally when a feature is not working as it’s supposed to be, due to a code issue, or if a new code has to be written and sometimes even because some environmental problem which needs to be taken care of through the code, a bug may qualify for a priority 2.Example of P2 issue can be a missing workflow.
• Priority 3 – Medium (P3) : This category is “Nice to have”. A bug with this priority can wait until a new version is created Sometimes even cosmetic errors such as expecting the correct error message during the failure could qualify to be a priority 3 bug.Example of P3 can be grammatical issues in the content.
• Priority 4 – Low (P4) : Very minute UI changes or cosmetic errors come under this category of bugs. Bugs with priority low are also opened to suggest some enhancements in the existing functionality or a request to implement a small change just to enhance a better user experience. Example of P4 can be to have a quick load time or a typo error.

We should understand the business needs, how a test case scenario can impact the end users and then figure out the severity and priority. We need to assign the severity level based on the issue type as this will affect its priority.
Do consider how much time it would take to fix the bug based on its complexity and time to verify it later.
Assigning wrong severity to a bug can delay the testing process and could have some drastic implication on the overall performance of the team.

About the author

Sanah, has 6 years of experience in the field of software quality. She has worked with various MNC’s in this short span of time and has been awarded with various awards. She is ISTQB certified and is currently residing in Arizona. When she is not ensuring an application is release defect free she likes to cuddle up dogs at the puppies meet.