Severity and Priority: Defects of High and Low Priority

Since all product companies can and probably use completely different tools for capturing and tracking bugs and related processes, such software eventually becomes a common system used for monitoring between different levels of management and technical staff.

Each defect contains a set of certain attributes such as severity and priority. Sometimes it’s not easy to understand the difference between these terms but still, every QA engineer should try to do this.

Severity and Priority

What is bug’s severity and how to set it?

Severity is a special attribute that helps to rapidly understand the level of technical influence a defect has on the overall performance of software that is being tested.

Each level of bug’s severity mostly complies with software performance, therefore, it’s a tester who is responsible for setting it.

Sometimes developers can directly take part in setting defect severity but usually, it’s a task of QA engineers. A tester should define a level each product’s function can affect the overall performance of a system.

Bug’s severity can be classified according to the following criteria:

1. Blocker — a bug that blocks the work. If this error appears in software that is being tested, further testing becomes impossible or hard. To continue testing, it’s needed to fix this error;
2. Critical — a critical defect. It can affect the way a system of a product you are testing functions. It’s a group of bugs that are constantly reproduced and can block software testing;
3. Major — a major error. It complexifies testing and using certain additional parameters;
4. Minor — a minor bug. It can slightly affect software performance or complexify working with certain systems;
5. Trivial — a trivial bug. It doesn’t affect software performance but spoils the overall impression of a project.

What is priority?

Priority is an attribute that can define the time needed to solve an issue (fix a bug).

When we talk about setting bug’s priority, we mean that a manager is the only one who is responsible for such work.

There are several types of priority:

1. Top — the highest priority. It should be added to all extreme cases that negatively affect the overall software performance. These defects should be debugged as soon as possible;
2. High — a high priority. It’s used for errors that should be fixed first of all;
3. Normal — a trivial (common) defect. It’s given to defects that can be fixed when tasks with higher priority will have been closed;
4. Low — a low priority, that can be given to bugs that don’t affect the functionality you are testing. Fixing such issues can be done after completing other important tasks and in case there are free resources and times.

Tips on how to set defect’s global priority

To be good at setting bug’s priority, you should understand frequency that primarily affects priority. Severity and priority directly affect the global priority of a defect found.

Its formula looks in the following way:

Global Severity = F(Priority, Severity)
Priority = F(BasePriority, Frequency)

As for the algorithm:

1. Set a severity of a bug found;
2. Leave aside severity since defect’s priority is in the first place;
3. Set the frequency of bug’s appearance, regardless of priority and severity;
4. Finally, define how frequency affects priority that you have already set.

We can display this in a form of the table:

Conclusion

Bugs and a software development process always go together, a list of defects found extends when the product’s launch is getting closer.

This means that a project group and a testing department should properly understand what these terms mean and how to use them.

If bug’s priority or severity is set improperly, this can decrease the overall efficiency of bug fixing.