Ask a junior QA engineer to explain the difference between Severity and Priority and watch them hesitate. This confusion is almost universal — and it matters enormously in practice. Misclassifying one for the other leads to wrong prioritisation decisions, wasted developer time, and production crises for "low-severity" bugs that turned out to be business-critical.
Let's untangle them once and for all.
Learning Objectives
By the end of this lesson you will be able to:
- Define Severity and Priority as distinct properties of a bug
- Classify bugs correctly using both dimensions independently
- Explain why High Severity / Low Priority and Low Severity / High Priority both make sense
The Definitions
Severity
Severity measures the technical impact of the defect on the system. It answers: "How badly does this break the software?"
Severity is determined by the QA engineer based on technical observation. It is a property of the defect itself, independent of business context.
| Severity Level | Description | Example |
|---|---|---|
| Critical | System crash, data loss, security breach | The application crashes for all users attempting checkout |
| Major | Core feature broken, no workaround | Users cannot submit the registration form |
| Minor | Feature partially broken, workaround exists | The date picker doesn't work; user can type the date manually |
| Trivial | Cosmetic issue, no functional impact | A button label has a trailing space |
Priority
Priority measures the business urgency of fixing the defect. It answers: "How quickly does this need to be fixed?"
Priority is determined by the product owner, business stakeholder, or team lead — based on business context, user impact, release timelines, and strategic importance. The QA engineer can suggest priority, but it is not theirs to set unilaterally.
| Priority Level | Description |
|---|---|
| High | Must be fixed before the next release |
| Medium | Should be fixed in the current sprint or next one |
| Low | Fix when capacity allows; not urgent |
The Four Quadrants
The power of separating Severity and Priority is that they can combine in all four ways, and each combination is legitimate:
High Severity / High Priority
The application crashes when users try to pay. This is both technically catastrophic and business-critical. Fix immediately.
High Severity / Low Priority
The export feature crashes when exporting more than 100,000 rows. Technically severe (a crash), but this feature is used by 0.3% of users, once per quarter. The release is tomorrow. Fix it after launch.
Low Severity / High Priority
The company logo on the homepage spells the brand name wrong. No functionality is broken. But this is visible to every new visitor, embarrassing for the company, and the marketing team wants it fixed before the campaign goes live in 2 hours.
Low Severity / Low Priority
A tooltip in the admin panel settings has an extra comma. Nobody notices. Nobody cares. Add it to the backlog and fix it when someone has 10 spare minutes.
Common Mistakes
Mistake 1: Treating Severity and Priority as synonyms. Every crash is not automatically "must fix today." Every cosmetic bug is not automatically "fix later." Assess them independently.
Mistake 2: Setting Priority yourself as a QA engineer. You can recommend priority, but the business stakeholder makes the final call. "This looks like High Priority to me because it affects the checkout flow — want to confirm with the PO?" is the right framing.
Mistake 3: Using only one scale. Some teams use a single "severity" scale for everything. This leads to conversations like "Is a broken logo more severe than a crash in a rarely-used feature?" — which is the wrong question. Use both dimensions.
Pro Tips
When filing a bug, always state your Severity clearly. Priority may be adjusted by the team, but your technical severity assessment is your professional input that shouldn't be left blank.
The business context changes Priority, not Severity. A crash is always Critical severity. Whether it's Priority High, Medium, or Low depends on when the next release is and who uses that feature.
Summary
- Severity = technical impact on the system. Set by QA. Based on the defect itself.
- Priority = business urgency of the fix. Set by business stakeholders. Based on context.
- They are independent — any combination of the four quadrants is valid.
- High Severity / Low Priority: technically bad, but low business urgency.
- Low Severity / High Priority: technically minor, but business-critical timing.