Bug Severity and Priority Matrix
Errors are of great importance in the software testing life cycle. For this reason, it is important to standardize this phenomenon so that all stakeholders can look at it from the same perspective and strive for the same goal.
In this article, as Hepsiburada, I will give information about the use and importance of the Severity and Priority fields in our bugs.
First of all, I would like to talk about what these two concepts are.
Priority
The concept of priority defines the order in which we need to resolve an error in Hepsiburada, as it does everywhere else. While implementing SDLC, we consider many points, but the priority of the bugs defines the speed at which the bug should be resolved, so it becomes one of the priority concepts for us. Because according to Hepsiburada the priority status is set based on the customer requirements.
The priority list used in Hepsiburada and its equivalents in the company are listed below.
Trivial: The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience.
Low: The defect is an irritant which should be repaired, but repair can be deferred until after more serious defect have been fixed.
Medium: This type of bug does not result in complete system failure or completely halt workflows or programs. However, Minor bugs usually cause significant annoyance or frustration among users and can reduce efficiency or productivity.
High: These bugs share many of the same criteria as show-stopper bugs. However, they are not classified as Show-stopper because they don’t completely halt the workflow or application. Additionally, high priority bugs can usually be avoided by using a workaround.
Critical: The defect is that impacts a major functionality of the application and the application cannot be delivered without fixing the bug
Severity
Severity is a broader metric, unlike other metrics. The exact equivalent of Severity is to create a perspective on how much the system is affected by this bug.
In addition, the fact that this concept works with priority as a support and a bit as a whole is one of the important building blocks for Hepsiburada.
The severity list used in Hepsiburada and its equivalents in the company are listed below.
Critical: The defect that results in the termination of the complete system or one or more component of the system and causes extensive corruption of the data. The failed function is unusable and there is no acceptable alternative method to achieve the required results then the severity will be stated as critical.
Major: The defect that results in the termination of the complete system or one or more component of the system and causes extensive corruption of the data. The failed function is unusable but there exists an acceptable alternative method to achieve the required results then the severity will be stated as major.
Moderate: The defect that does not result in the termination, but causes the system to produce incorrect, incomplete or inconsistent results then the severity will be stated as moderate.
Minor: The defect that does not result in the termination and does not damage the usability of the system and the desired results can be easily obtained by working around the defects then the severity is stated as minor.
Cosmetic: The defect that is related to the enhancement of the system where the changes are related to the look and field of the application then the severity is stated as cosmetic.
Let’s look at the matrix of these two concepts.
Priority maps to possible resolution priority of Bug, while Severity shows its value on system impact. In this context, more than one possible combination may be required for the same bug.
The table below shows a clearer opening of the data. Decisions were examined in 5 main classes. However, considering the extreme probability points, a 4-level table is observed.
Sample of extreme probability points,
High Severity — High Priority — Level 1 : Most of the errors in this area are caused by breaking critical paths and causing errors. Thanks to this seriousness, it is the first area to be fixed.
Example, one of the most important steps in the e-commerce site is the payment methods. Any error that may occur in the payment systems in this process is categorized at this level.
High Severity — Low Priority — Level 2 : The priority of the level of the bugs in this area is important, but in the severity part, the priority order of the bugs should be fixed immediately, but in addition, the system is not affected much by this bug.
Example, Not being able to reach the product comment page can be categorized in this area. In this process, there was a breakdown in the system properties. However, since this breakdown is not on the main flow, it would be appropriate to categorize it at this level.
Low Severity — High Priority — Level 3 : These are the level of bugs that the system is almost not affected by, but can primarily harm the customer or the company.
Example, A logo error that occurs on e-commerce sites can be categorized in this area. This error, which will damage the brand reputation in this process, is categorized at this level, since it will not have any serious reflections on the customer side.
Low Severity — Low Priority — Level 4 : It is the bug level that has almost no effect on the system and the customer, and generally only spoils the perception of user friendly.
Example, Terms and conditions of use links not working or redirecting to the wrong place can be categorized at this level. Since it does not have a very large usage rate, it is categorized from the lowest level.
When working with extreme probability points, it is possible to reach the following levels. In Hepsiburada, we decide with our Product group according to these levels and we decide accordingly.
To give a few examples,
Same Severity,
In this example Priority is marked as Major (Level 4) while Severity is marked as Level 4.
Contrary to the other example, in this example, Priority is marked as Trivial (Level 1) while Severity is marked as Level 4.
Same Priority,
In this example Priority is marked as Minor (Level 2) while Severity is marked as Level 5.
Contrary to the other example, in this example, Priority is marked as Minor (Level 2) while Severity is marked as Level 1.
As shown in the examples above that, it can exist with different levels of probability and that synchronization these concepts is not necessary.
With the use of this feature, which is found in our bugs specifically in Hepsiburada, Product and Development teams can look at bugs from the same perspective. This gives us additional speed and stability in solving our bugs. It is possible to say that we have strengthened our defect management system by sticking to this concept.
In this process, we are paving the way for us to work in accordance with the agile process, and we provide our limited resource and time management according to these areas. And in bug management, the decisions of the bugs to be included in the sprint are determined with a healthier method. Thanks to that process we always support our Agile system and we are avoiding overworking process.
While prioritizing our critical bugs, we are committed to providing a more sustainable structure to our customers. In addition, we aim to make bug classifications with a more effective method and complete the process as quickly as possible.
An additional benefit for us in this process is that it enables us to work with the highest efficiency in terms of performance. Thanks to this efficiency, we plan to prevent possible bug structures.
To sum up, we brought this phenomenon into our lives in order to run towards the same goal within the framework of Hepsiburada. We observed firsthand how this contributed to us. We observed improvements from the reports used to the quality of our bugs.
