Severity and Priority in testing

In this section, we will learn about the severity and the Priority of a bug in software testing

Severity

The impact of the bug on the application is known as severity.
It can be a blocker, critical, major, and minor for the bug.

Blocker: if the severity of a bug is a blocker, which means we cannot proceed to the next module, and unnecessarily test engineer sits ideal.

There are two types of blocker bug, which are as follows:

A major feature is not working: Login to HDFC, amount transfer is not working

The major flow is not working: Login and signup itself not working in HDFC application.

Critical: if it is critical, that means the main functionality is not working, and the test engineer cannot continue testing.

Major: if it is major, which means that the supporting components and modules are not working fine, but test engineer can continue the testing.

Minor: if the severity of a bug is major, which means that all the U.I problems are not working fine, but testing can be processed without interruption.

Priority

Priority is important for fixing the bug or which bug to be fixed first or how soon the bug should be fixed.

It can be urgent, high, medium, and low.

High: it is a major impact on the customer application, and it has to be fixed first.

Medium: In this, the problem should be fixed before the release of the current version in development.

Low: The flow should be fixed if there is time, but it can be deferred with the next release.

Note: The test engineer decides the severity and Priority, and the developer can also change the severity with a proper reason and comments on the bug reports.
A developer cannot change the Priority, because if the developer changes the Priority, he/she may fix the easy bug's first.

Example of severity and Priority

Example 1

Suppose we have to send the priority means which bug needs to fix first according to the requirement of the client.

• When the bug is just found, it will be fixed in the next immediate build, and give the Priority as P1 or urgent.
• If the Priority of the bug is P2 or high, it will be fixed in the next 3-4 builds.
• When the Priority of the bug is P3/medium, then it will be fixed in the intermediate build of the application.
• And at last, if the Priority is P4/low, it will be fixed in the last 2-3 build of the software as we can see in the below image:

Example 2

If we take the case of a login module, then the severity and Priority could depend on the application like as we can see in the below image: