What is bug severity and why indicate it?
My name is Sergey, I am a QA engineer in Archy. Having tested a great number of different mobile applications, I realized that properly classified bug severity has a significant effect on the further development process. It is essential to understand how severe the bug is before handing it over to the project manager. This will make it easier for both the project manager and the developer. In this article, we are going to look into what bug severity is and why we should indicate it. We are going to use the bugs that I’ve encountered as an example.
What is bug severity?
Severity is an attribute that characterizes the impact a defect has on the application performance. Defect severity is divided into five levels:
1. Blocker
A blocking error crashes the application, making it impossible to work with the system we’re testing or its key functions. Solving this problem is necessary for the further functioning of the system.
2. Critical
An error can be called critical if, for example, key business logic does not work properly, or there is a hole in the security system. It’s an issue that causes a temporary server crash or a part of the system to crash. It is not possible to solve the problem using other entry points.
3. Major
A significant error, when a part of the core business logic does not work correctly. The error is not critical, or it is possible to work with the function we are testing using other entry points.
4. Minor
A minor error does not interfere with the business logic of the tested part of the application. It’s a user interface problem.
5. Trivial
A trivial error does not deal with the business logic of the application. It’s a hard-to-reproduce problem, barely noticeable through the user interface. It can be a problem with third-party libraries or services, and it does not affect the overall quality of the product.
Why do we need to classify the severity of bugs that we find?
Before the bug gets to the project manager, you need to indicate its severity. It’s important to do it right. If the deadline was yesterday, the project manager, probably loaded with other tasks, will pay attention only to the severity attribute and assign developers to work on bugs based solely on this information. If bug severity is indicated incorrectly, all minor and trivial
bugs can be fixed, but the blocker bug will remain. As a result, we get an application that is blocked after incorrect authorization, but the user interface is cool. We can still say that this is not a bug, but a feature, but what’s the point if your customer is crying?
How to classify bug severity correctly?
When finding a bug, you need to analyze what it affects and compare it with five levels of the severity scale. To make it clearer, let’s look at the examples of real bugs.
1. “ACTE” app. Trivial bug. A photo cannot be selected fully. The corners of the photo remain unselected.
“Eda” app. Trivial bug. The timer icon has visible pixels.
2. “CarePlus” app. Minor bug. The application works properly; freezing menu animation affects only the user interface. If you move the menu from side to side, the bug disappears.
3. “ACTE” app. Major bug. Tabs “templates” and “created” may disappear, which makes it impossible to work with them. The bug occurs when you click the button that opens another application within this one and when you hit the “back” button.
4. “Eda” app. Critical bug. When you first start the application there is an instruction; it can also be found when we press “more” on the tap bar. If you hit that button and scroll down the instruction, the app crashes.
5. “CarePlus” app. Critical bug. When pressing any tab on the menu and the “back” button simultaneously, the app opens a window which you cannot close.
A full understanding of bug severity will come over time. The more bugs you find, the easier it is to determine their severity. Do not forget about this attribute, since properly indicated bug severity can significantly help the whole team and demonstrate your professionalism in the field.
