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 levels
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 user (end-user, operator, etc.) or system data loss.
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 portions of a functional area.
5. Cosmetic error
Bugs could allow normal functionality but with significant blemishes (especially in UI or system responsiveness).
Priority levels
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 the feature, budget, and schedule constraints (if possible); otherwise, in the next scheduled release.
5. Discretionary – Bugs can be resolved whenever possible in future releases, allowing for other priorities.
*Read more about this topic in Rex Black’s Critical Testing Processes: Plan, Prepare, Perform, Perfect, chapter 2.
Tips
Remember that the bug priority and severity levels 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.
Conclusions
Make sure always to add the correct criticality level. The bugs need to be better prioritized to avoid 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.
Stay Updated with the Latest in QA
The world of software testing and quality assurance is ever-evolving. To stay abreast of the latest methodologies, tools, and best practices, bookmark our blog. We’re committed to providing in-depth insights, expert opinions, and trend analysis that can help you refine your software quality processes.
Delve deeper into a range of specialized services we offer, tailored to meet the diverse needs of modern businesses. As well, hear what our clients have to say about us on Clutch!
