QA | Severity and Priority Guide

Severity defines the degree of impact of a bug on a software application to produce detrimental results. Greater the severity, the greater the impact on functionality and operation of a system.

Priority defines a bug in terms of the degree of impact on the business and users. The Higher the Priority, the sooner the bug will be resolved.

A label is just a label.

It is far more important to understand what stands behind them, so people can easily say when to assign a certain severity to a bug and understand what such severity means in terms of business impact. This is important because depending on the severity, your stakeholders may take appropriate action. E.g. stop releasing the product or postpone fixing the bug.

What Is a Defect?

A defect is a shortcoming, an imperfection or a flaw in any system, which deviates the actual result from the expected one. Moreover, when the result does not meet the requirements or expectations of the end-user, it is termed as a defect, error, or a bug.

Key Differences Between Severity and Priority

Severity Meaning

Critical: Functionality is completely down due to which tester cannot do further testing.

Major: Functionality of the app is not working but the tester is able to test the application.

Moderate: Logical defects which do not block any functionality and cause some undesirable behavior but the system is still functional.

Minor: Almost no impact on the functionality. Does no harm to the application under test.

Priority Meaning

⏫Urgent: The business is directly impacted. We are potentially losing money or causing customer pain. We need to act immediately to remedy the problem.

⬆️High: A defect having high business value where end user experience is poor, but there is a current workaround. We should remedy the issue as soon as Urgent issues are resolved.

↕️Medium: End-user can work using workaround but some functionalities of the software/application cannot be used. This defect may be fixed after the release.

⬇️Low: This defect may or may not be fixed and can be scheduled when time is available.

❓ Questions to help decide the measure of Severity

1. Does the system allow me to work even after defect occurs?
2. Does the system recover from the defect?
3. Did I check whether the same defect is reflected in all other sections or the entire system?
4. Can I replicate the defect in some other system having the same configuration (OS, browsers, etc) as that of the system where I found the defect?
5. Can I repeat the defect in other environments?
6. Does the defect affect all categories of user or only a particular category?
7. How frequently does the defect occur?
8. What are the inputs (scenario) which cause the defect to occur?

⚠️ Caution

Disagreeing on Defect Severity is a Tale as Old as Time. This is still a very subjective matter and chances are high that one developer or tester will not agree with the definition of the other. Normally, Testers have the final say on Defect Severity while the Project Management / Product Management / Client has the final say on Defect Priority.

Examples of Bugs

( Minor Severity | ⬆️***High Priority )*** Low severity would not affect the working of the website but may be put in the basket of high priority if the content might be reflecting the brand image & objectives of the company at first sight to the customers.

( Critical Severity | ⏫***Urgent Priority )***

There may be an issue with User Login or Home page — significant modules or features — which are frequently accessed functions. Login is the entry point for the customer to explore a personal dashboard, and the defect may be established as Urgent priority to resolve ASAP.

( Minor Severity | ⬇️***Low Priority )***

A paragraph containing minor spelling or grammar mistakes that any reasonable person would read past but still not be influenced in a purchasing decision. It’s embarrassing, but doesn’t break anything.

( Major Severity | ↕️***Medium Priority )***

Checkout application can calculate tax properly for purposes of customer total and is billed correctly, but the itemized list isn’t displaying the value for the user to verify. It won’t break the user from being able to complete their purchase, but it might cause some users to try to call in, and might prevent some customers from deciding to move forward.

1044–2009 — IEEE Standard Classification for Software Anomalies — IEEE Standard

This standard provides a uniform approach to the classification of software anomalies, regardless of when they originate or when they are encountered

Learn More: What Mobile Testing Really Means

Now with 20 years of experience, Dan Emmons strives to make issues that seem complex, overwhelming, or insurmountable more manageable for the Team, and to provide exceptional service that exceeds clients’ expectations. For more information, contact him on LinkedIn or through Emmonspired LLC.