QA or PM: Who really decides the priority levels of bugs reported?

I remember being asked in one of my first interviews what priority levels were and to give the difference between priority and bug severity. Mind you, I was fresh out of a QA boot camp, and I gave a very vague answer. The interviewer, who had years of experience, could see right through me. Well, at least I tried my best, right? 😂

After the interview, I had to do my research on the topic, and to my surprise, it wasn't that difficult. In this article, I'll be talking briefly about bug priorities and severity. I'll also be talking about who decides the priority of bugs reported.

What are priority levels?

In software development, priority levels are basically a classification that indicates how soon a task, issue, or feature request has to be addressed.

You can think of it as a ranking system, which helps us decide which task should go first. These priorities are directly related to how quickly a bug needs to be fixed.

Common Priority Levels:

The terms may vary in organisations, but the most common priority levels include

1. Critical Priority (P0)

2. High Priority (P1)

3. Medium Priority (P2)

4. Low Priority (P3)

I'll be explaining these priority levels using scenarios from a blog website as examples.

1. Critical Priority (P0):

These are the most urgent issues, often labeled as P0. They usually involve system crashes, data loss, or major functional failures that stop users from using the software as intended.

For example, a critical issue on a blog website would be users being unable to publish articles. While this isn't a system crash, it’s a significant functional failure because publishing is a core feature of the platform.

2. High Priority (P1):

These are serious issues that need quick attention and are labeled as P1. They have a major impact on the user experience or important features. Even though they might not crash the application, they still need to be fixed right after critical issues.

The inability of users to view the number of views on a published article is an example of a high priority bug on a blog website. Although this doesn't cause the website to crash, it interferes with a crucial function and keeps users from seeing the article's reader count.

You might be wondering why views on a website should be regarded as a high-priority bug. Many publishers, whether companies or individuals, measure the effect of their articles by counting the number of users they've reached. Blog analytics are also of high importance to them. Depending on the type of blog, this could be considered a critical bug, but in most cases, it would be classified as a high priority.

3. Medium Priority (P2):

These may involve minor functional issues or usability problems it is usually labeled as P2. They do not affect the core functionality of the application.

An example of a medium-priority issue on a blog website would be the author's profile pictures are not displaying on blog posts. This is a medium-priority issue because the main content, like reading, writing, and publishing blogs, still works perfectly, and it doesn’t block users from engaging with posts.

4. Low Priority (P3):

These are minor issues that don’t affect how the app works. They’re usually small bugs that users may not even notice. They don’t need to be fixed right away and don’t impact the overall experience.

An example of a low-priority bug on a blog website could be the wrong icon being displayed or a situation where the requirement states that the colour of the Publish button should change when you hover over it with the cursor, but it doesn't. As long as the button still works as expected, this issue can be addressed at a later time.

What are severity levels?

Severity levels describe the impact of a bug on the application. Let me explain. Severity levels check how serious a bug or defect is based on how it affects the application or the overall user experience.

Common severity levels:

So, the exact names and number of levels might change a bit from one organization to another, but here are some common severity levels you might come across

1. Critical Severity

2. Major Severity

3. Minor Severity

4. Trivial Severity

I'll also be explaining these with examples from a blog website

1. Critical Severity

These are major issues that completely stop the application or an essential feature from working. They affect the application by preventing the user from completing their main task, and usually, there’s no workaround.

An example of a critical severity bug on a blog website is when published articles are clicked the web application crashes. In this case, there's no workaround for the users, they won't be able to read the published article or be able to go back.

The image below displays an example of a critical bug. (Note: this is not an issue on Hashnode; the image was generated for this example.)

2. Major Severity

These are serious issues that affect a system's core functionality but still allow the program to function in a limited way there may be a workaround-based capacity. While the entire system might not be down, a significant portion is unusable or works incorrectly.

An example of a Major Severity bug on a blog website would be when the information entered by a user during registration is saved incorrectly in the system. This leads to the wrong user information being saved, and Loss of trust if users realise their data was altered without their action.

An example is displayed below. (Note: this is not an issue on Hashnode; the image was generated for this example.)

3. Minor Severity

These flaws have a minor effect on the software's functionality. They could include visual flaws, typos, or minor UI differences that do not significantly hinder the user experience.

An example of a minor severity would be the profile picture not being displayed beside the article. because this is a visible part of the blog and users expect to see it, it can be classified as a Minor severity.

An example is displayed below. (Note: this is not an issue on Hashnode; the image was generated for this example.)

4. Trivial Severity

This is the lowest level of severity. It’s similar to minor severity, but in this case, the bug happens in less visible or less visited areas of the application and doesn’t affect the core user experience. These bugs don’t need urgent attention.

An example would be the wrong icon appearing in the dropdown on a blog website, which is probably a rarely used feature.

An example is displayed below. (Note: this is not an issue on Hashnode; the image was generated for this example.)

What’s the difference between minor severity and trivial severity?

Sometimes, the same bug can be classified as either minor or trivial, depending on where it happens.

Now we'll be using the profile picture not loading as an example for both.

If this is missing in a less important section, like a sign-in dropdown for new users. The user might not even notice it if it is absent from a less crucial area, such as a dropdown for new users. The problem would be categorised as trivial severity in this instance.

However, a minor severity would be categorized when it is more obvious and detracts from the application’s visual appeal. An example would be if the profile picture is absent next to a published article that readers frequently view.

The location and visibility of the problem usually help in determining the severity level, even though both bugs involve the same feature (a missing image).

Who Sets the Priority?

Now the big question we have been waiting for: who sets the priority?

The priority is usually set by the Product Manager (PM), but it’s often a collaborative decision involving the QA team, developers, and sometimes customer support or business stakeholders.

QA engineers report the issue and set the severity level of the issue which explain its impact clearly.

Developers assess how complex or risky it would be to fix the issue.

PMs look at how the issue affects users, compares it with the developers’ assessment and compares it to the business goals before setting the priority.

Think of it this way:

If a football player injures both his legs and fingers, the QA engineer notices the injured player and assesses how each injury might affect his performance in the next game.

The QA might say, “Since the player needs his legs to run and play, we should treat the leg injury first. The fingers can wait.” From a technical perspective, the leg injury is more severe.

But the Product Manager (PM) looks at it from a business angle and says, “The player needs to sign a major contract soon, and he needs his fingers for that. If he can't sign, the team could lose a valuable deal.”

So even though the leg injury is more severe, the finger injury becomes the higher priority—because it affects the business goal more directly.

(Yes, we know e-signatures exist, but for this example, let’s pretend they don’t! 😉)

So, like the image below shows, instead of arguing over what should be fixed first, let’s work together to achieve both customer satisfaction and business goals.

At the end of the day, collaboration is what gets bugs fixed. I hope this clears up the burning question!

Thanks for reading 😊