Severity and Priority: How to Prioritize Bugs
Severity and priority are common interview topics and frequent sources of workplace confusion. Beginners often equate them, but they describe different things: severity measures technical and user impact, while priority indicates how urgently the business and team need a fix.
What severity means
Severity describes how strongly a defect affects the system, users, or a critical scenario. It reflects the scale and depth of the problem. Crashes, inability to complete payments, and data loss have high severity. A typo in a text field has low severity.
- →Severity asks: how serious is the failure?
- →It describes a defect's impact.
What priority means
Priority indicates how soon to fix a problem. It includes business context alongside technical considerations: release dates, feature importance, reputational risk, marketing campaigns, and customer commitments.
- →Priority asks: how urgently should we fix this?
- →Priority may depend on the release context.
Why severity and priority differ
A severe bug often deserves the highest priority, but not always. A critical defect in a rarely used legacy module may receive a lower priority than a visible home-page error before an important launch. Similarly, a minor storefront bug may be urgent because of business risk.
- →Severity concerns impact; priority concerns work order.
- →Priority assessment without business context is almost always incomplete.
Common combinations
High severity and high priority: a key user journey is broken. High severity and low priority: a rare but serious defect affects a low-importance scenario. Low severity and high priority: a small visible issue affects a prominent area before release. Low severity and low priority: a cosmetic issue has no user or business impact.
- →These combinations help avoid overly linear thinking.
- →The most useful skill is explaining the assessment you chose.
Who sets severity and priority
Practices vary. QA often proposes severity, while priority is discussed with the product owner, manager, or lead. Severity may also need collective calibration. Use these fields for deliberate prioritization rather than as formalities.
- →Discuss severity and priority within a shared context.
- →Without agreed scales, assessments become inconsistent.
Common beginner mistakes
The most common mistake is rating every bug high/high. Others include considering only the user's perspective while ignoring release context, and confusing technical seriousness with urgency. Good QA engineers explain their ratings clearly to the team.
- →Do not inflate severity because of frustration.
- →Do not understate priority when a bug materially affects a release or customer.
Conclusion
Severity and priority describe two separate dimensions. Severity shows how serious the problem is; priority shows how urgently it needs fixing. Understanding this distinction helps teams make sound defect decisions.