Severity and priority. Examples of the bugs with high severity and low priority and vice versa

The organizations using different tools for tracking defects and related processes make these instruments the common tracking system between various management levels and technical staff. Every bug has the «Severity» and «Priority» attributes. Sometimes it seems that there is no difference between these two notions, or it is not apparent. But the severity relates more to the technical part and the priority to the organizational one.

Severity

Severity is an attribute that characterizes the level of bug influence on the general functionality of the tested product.

The severity degree corresponds more to the functionality. Therefore, it is assigned by the tester. Sometimes the developers affect the bug severity, but it depends on the testers more often. They assess how much the specific function can influence the general functionality. 

One of the types of bug severity classification:

Blocker. The bug that blocks the further work of the site. All the following work with the program becomes impossible because of it. The defect must be fixed for the system to continue functioning.

Critical. A critical bug that violates the operation of the basic functionality of the tested product.

Major. Major defects make the operation of the basic functionality more difficult or make using additional functions impossible.

Minor. A minor defect has little impact on the system's functionality or has obvious workarounds and complicates using the additional functions.

Trivial. A trivial defect that does not affect the project functionality but leaves a negative impression on the product work.

Priority

Priority is an attribute that determines the required speed to fix the bug.

When it comes to the bug priority assignment, even though the tester assigns it first, it is determined by the product managerб who has a general idea about the tested system and how fast the bug should be fixed. 

Top. It is the highest priority assigned to the urgent situations that negatively affect the product or even business of the company and related to the defects requiring immediate correction.

High. The high priority is assigned to bugs that must be fixed first.

Normal. It is the standard priority defined by default. It is assigned to the bugs that do not need to be fixed in the first place.

Low. The low priority is assigned to the bugs that do not affect the functionality. They are fixed last when there is time and resources for it.

Frequency is the rate of customers' number that find the defect. It is derived from algorithm analysis and users' means of interaction.

• High: 80% and more visitors find this error;
• Medium: from 30% to 80%;
• Low: from 10% to 30%;
• Very low: less than 10% of visitors encounter this error.

How to identify the global priority of the bug (Global Severity)

To determine the algorithm of the global severity, it is required to find out the frequency that affects the priority. The priority and severity, in turn, affect the global severity of the bug:

Global Severity= F(Priority, Severity), accordingly

Priority = F(BasePriority, Frequency)

Algorithm for determining global priority:

1. Specify the severity of the bug.
2. Specify the priority of the bug without paying attention to the severity.
3. Determine the frequency of the bug, irrespective of severity and priority.
4. Calculate the influence of the frequency of the priority specified initially.

• If the frequency is high, it means the priority should be changed to one level. For example: if the priority was «normal», it should be changed to «high»;
• If the frequency is medium, the priority is changed only from «low» to «medium». For the «high» priority, the value isn't changed.
• When the rate is low or insignificant, the priority is left unchanged.

The global priority finding:

Accordingly, the bug must be fixed in case of the «Critical» global priority. Defects with the «Minor» priority should also be resolved before release, but a small amount of them is allowed in the project. The «Trivial» bugs can be left unchanged altogether.

The high priority and low severity

Any insignificant severity defects that affect the user experience automatically become part of this category. It also includes bugs that require fixing but do not affect the application. 

Example 1

The buttons overlap each other. They are clickable as before, but the visual perception of the product is distorted.

Example 2

The company logo has a spelling mistake on the main page. It does not affect anything in terms of functionality, but the same can't be said for the user experience. Therefore, this bug should be resolved with a high priority, even though it has a minimum impact on the product.

The high severity and the low priority 

It is a defect that appears in the application's functionality (and there are no workarounds) and doesn't allow working with the system but is rarely used by the end-user.

Example 1

The main page of the site is displayed wrong in the old browsers. For example, the text is overlapped, or the logo does not load. It affects the proper product functioning and user navigating the site, that is why the severity will be high. Nevertheless, as the browser is old and the number of visitors is small, the priority of the bug is considered low. 

Example 2

Suppose there is a banking application that correctly calculates daily, monthly and quarterly reports, but there is a problem with the annual report. This is the high severity defect, but with low priority, because at the moment, the annual reporting function is not relevant. This bug can be fixed in the next release.

Such defects should be corrected, but not immediately. It can be implemented in the case of special testing. These errors usually affect the functionality but reveal themselves only after using some uncommon incoming parameters.

The conclusion

Defects and software development are closely linked. The more the product grows, the more defects appear. The priority and severity of the bug are the key factors used to decide what to fix in the first place. It is therefore important for testers and developers to understand the proper definition and use of both terms. In case of the wrong severity and priority assignment, the whole error fixing process will lose effectiveness. It, on its part, might damage the business and result in financial losses. Consequently, a better understanding of priority and severity is crucial for the team to prosper and make the right and effective decisions.