What is the difference between Priority and Severity?

ISTQB definition:

Severity - the degree of impact that a defect has on the development or operation of a component or system.

Priority - The level of (business) importance assigned to an item, for example, a defect.

Severity classes could be:

Critical: defects will cause downstream damage; the scope and impact of the defect are beyond the work product under inspection.

Major: defects could cause a downstream effect.

Minor: defects are not likely to cause downstream damage.

ISTQB Glossary

Human language:

The words priority and severity do come up in bug tracking. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, give the team complete information, so developers can understand the bug, get an idea of its severity, reproduce it, and fix it. Severity and Priority are two of the most important attributes that can assign to a bug because the fixes are based on project priorities and the severity of bugs.

Although they both serve a similar purpose, they still vary a lot. Before looking at the key differences and examples of these terms, let's consider each of them separately

What Is Priority

Priority - defines the order in which we should resolve a defect, and answer the questions: How quickly a bug should be fixed, should we fix it now, or can it wait? Priority is used in the comparison of two things or conditions, where one has to be given more importance than the other, and has to be resolved first before proceeding to the next one.

While creating a defect, the tester generally assigns the priority initially to the developer, mentioning the time frame to fix the defect as he views the product from the end-user perspective. If high priority is mentioned, then the developer has to fix it as soon as possible. If there are multiple defects, the priority decides which defect has to be fixed and verified immediately versus which defect can be fixed a bit later.

Basically, the priority status comes into play according to the customer’s requirements. Any business stakeholders including the project managers, business analysts, and product owners define the priority of the defects. Depending on the bug-tracking systems, priorities may differ.

Usually, priority classifies as follows

Critical (P1)

It is set in the case when a bug has to be fixed immediately. This generally occurs in cases when an entire functionality is blocked and no testing can proceed as a result of this. Any defect that needs immediate attention and impacts the testing process will be classified under the Critical category.

High (P2)

It is set in the case when a bug should be resolved to match the “exit” criteria before the release is made. The defect must be resolved as soon as possible because the defect is affecting the application. The system cannot be used until the repair has been done. Normally It happens when a feature is not usable as it’s supposed to be, due to a program defect, or that new code has to be written, or sometimes even because some environmental problem has to be handled through the code.

Medium (P3)

It is set in the case when a defect should be resolved after all the serious bugs are fixed. A defect with this priority must be in contention to be fixed, as it could also deal with functionality issues that are not as per expectation. Usually, the fix may be considered after the deployment of an upcoming release or the next one. Sometimes even cosmetic errors such as expecting the right error message during the failure could qualify to be a Medium priority.

Low (P4)

It is set in the case when a defect indicates that there is definitely an issue, but it doesn’t have to be fixed to match the “exit” criteria. Typically, some typing errors or even cosmetic errors as discussed previously could be categorized here. The bug is given the least attention. It may or may not be placed under the development bucket. Sometimes defects with priority low are also opened to suggest some enhancements in the existing design or a request to implement a small feature to enhance user experience.

What Is Severity

Severity - defines the impact that a given defect has on the system and answers the question: How critical the defect is, and what is the impact of the defect on the whole system’s functionality?

The severity of a problem is defined in accordance with the customer’s risk assessment. The severity is a parameter set by the tester while he opens a defect and is mainly in control of the tester. Depending on the bug tracking systems, the severity may differ.

Usually, severity classifies as follows

Critical (S1)

It is set in the case when the failed function is unusable and there is no acceptable alternative method to achieve the required results. Any catastrophic system failures like crashes that could lead the user to non-usability of the applications could be classified under Critical severity. Critical is a defect that completely hampers or blocks testing.

Major (S2)

It is set in the case when the feature implemented is not meeting its requirements/use case(s) and behaves differently than expected. A major defect occurs when the functionality not doing what it should be doing.

Minor/Moderate (S3)

It is set in the case when the impact is negligible to some extent, or it doesn’t have a major impact on the application. A minor, low-severity bug occurs when there is almost no impact on the functionality, but it is still a valid defect that should be corrected. The defect that does not damage the usability of the system and the desired results can be easily obtained by working around the defects.

While opening defects, it’s a tester’s responsibility to assign the right severity to the defects. Incorrect severity and hence priority mapping can have very drastic implications on the overall STLC process and the product as a whole.

Difference Between Severity And Priority

Bug Severity is determined by a Quality Analyst, and a Test engineer VS Bug Priority is determined by the Product Manager or Client;
Bug Severity is basically a parameter that denotes the total impact of a given defect on any software, VS Bug Priority is basically a parameter that decides the order in which we should fix the defects;
Bug Severity examines whether the impact is serious or not VS Bug Priority examines whether the bug should be resolved soon or can be delayed;
Bug Severity is operated by functionality VS Bug Priority is operated by business value;
Bug Severity is associated with standards VS Bug Priority is associated with scheduling;
In the case of bug severity, the level of severity is less likely to change VS Bug Priority may change more often.

Life example:

Example 1: Bug with High Severity and Low Priority

Imagine that we faced such a problem during browsing on any website: After fast switching between categories of the main menu 20 times in a row, the website crashed with the error - Sorry, something went wrong, please try again later.

In that case, the severity is High due to the issue breaking the website, however, this is not a user experience to make fast switching between categories of the menu 20 times in a row, there is a very small chance that this problem will be reproduced by a real user while using the site. Therefore, the Priority to fix this issue is set to Low.

Example 2: Bug with Low Severity and High Priority

Imagine that we faced such a problem during browsing the Coca-Cola website: On the Home Screen, the logo is displayed with the text: Coca - CoPa. In that case, the Severity is set to Low due to this spelling issue can be fixed easily, but due to it affecting the Brand's reputation, this issue should be fixed as quickly as possible, therefore the Priority is set to High.

Conclusion:

So, if you are asked at an interview: What is the difference between Priority and Severity? The best way to answer is:

Priority - defines the order in which we should resolve a defect, and answer the questions: How quickly a bug should be fixed, should we fix it now, or can it wait?