Here’s a good practice for ticket workflow – add priority and severity levels.
Bug Priority vs. Severity Levels
Although they’re connected, it’s important to note the differences between them.
- Who sets the priority of the bug?
Stakeholders, project managers, the product owner, or the client. This helps prioritize the workflow based on the business needs.
- Who’s responsible for adding severity levels?
The QA is usually in charge of it when creating the bug. A severity level is added based on the criticality and complexity of that bug.
Severity: The degree of impact a defect has on the development or operation of a component or system.
(ISTQB Definition, see more on https://www.istqb.org)
The defect severity can have different classifications based on the project, organization, tracking tool, etc.
There’s a scale of how threatening a bug is for the system. It ranges from level 1 (most damaging) to level 5 (least damaging)
1. Loss of data
Bugs could cause loss of user (end-user, operator, etc.) or system data.
2. Loss of functionality
Bugs could block the use of a major functional area.
*Can include nonfunctional problems (e.g., performance) that impose delays in functionality.
3. Loss of functionality with a workaround
Bugs could block the use of a major functional area, but a reasonable affected-user workaround exists.
4. Partial loss of functionality
Bugs could block some unessential portion of a functional area.
5. Cosmetic error
Bugs could allow normal functionality but with significant blemishes (especially in UI or system responsiveness).
Priority: The importance of fixing bugs is based primarily on the ability of the system to meet customer needs.
*We could also include logistical project issues, regulatory or standards compliance, or other business considerations.
The priority scale ranges from 1 (most important to fix) to 5 (least important to fix).
1. Urgent – Bugs require immediate resolution.
2. Essential – Bugs are a must-fix for release.
3. Valuable – Bugs could significantly reduce the value of the system to one or more customers or users.
4. Desirable – Bugs could be fixed in this release within feature, budget, and schedule constraints (if possible); otherwise, in the next scheduled release.
5. Discretionary – Bugs can be resolved whenever possible in some future release, allowing for other priorities.
*Read more about this topic in Rex Black’s Critical Testing Processes: Plan, Prepare, Perform, Perfect, chapter 2.
Keep in mind that the bug priority level and severity level don’t always coincide. Although a defect has critical severity, it might not be the highest priority for the client and vice versa.
For example, a Critical issue with Low priority is when the application crashes after taking steps normal users don’t usually follow (like adding more than 50 phone numbers on an account registration page).
A Trivial/Minor bug can have a High priority when an image is truncated and not centered. This issue will probably have a high priority for the client since it directly affects UX.
This represents one of the most common causes of conflict between the QA and the Developer. The QA will set a bug to urgent, while the Developer will consider it discretionary.
Make sure always to add the correct criticality level. The bugs need to be better prioritized in order to avoid any conflicts with developers.
At the same time, don’t worry if a Low priority issue is added to an Urgent issue. Fixing it is probably not crucial for reaching the company goals at the moment.
If you want to get in touch, we’re always available for a chat:
While you’re here, you should also check out our article on how to add a bug: