The Critical Distinction
Severity and priority are the two most confused concepts in bug management. Getting them wrong leads to misallocated resources — critical bugs get ignored while cosmetic issues get urgent attention.
Severity = How bad is the impact on the system? (Technical assessment) Priority = How soon should it be fixed? (Business decision)
They are related but independent. A bug can be high severity but low priority, or low severity but high priority.
Severity Levels
Severity is an objective, technical assessment of the bug’s impact on the system.
Critical (S1)
System crash, data loss, security breach, or complete feature failure with no workaround.
Examples:
- Application crashes on launch for all users
- Payment processing charges credit cards twice
- User data exposed to unauthorized users
- Database corruption causing data loss
Major (S2)
Major feature broken or significantly degraded, but the system does not crash. Workaround may exist but is difficult.
Examples:
- Login fails for users with two-factor authentication enabled
- Search returns incorrect results for queries with special characters
- Export to PDF generates corrupted files
- Shopping cart loses items after page refresh
Minor (S3)
Feature works but with cosmetic issues, minor usability problems, or edge case failures that most users will not encounter.
Examples:
- Date format shows MM/DD/YYYY instead of DD/MM/YYYY for European locale
- Tooltip text overlaps with adjacent button on small screens
- Sorting works but defaults to ascending instead of descending
- Profile picture upload works but shows a brief flash of the old image
Trivial (S4)
Cosmetic issues with zero functional impact. Typos, misaligned elements, minor visual inconsistencies.
Examples:
- Typo in footer: “Copyrite” instead of “Copyright”
- Button color is #0066CC instead of the design spec #0066FF
- Extra whitespace between two paragraphs
- Inconsistent capitalization in menu items
Priority Levels
Priority is a business decision about when the bug should be fixed.
P1 — Immediate (Fix now)
Must be fixed immediately. Blocks release or causes active harm to users or business.
P2 — High (Fix this sprint)
Should be fixed in the current sprint. Important for release quality.
P3 — Medium (Fix next sprint)
Should be fixed soon but can wait for the next sprint.
P4 — Low (Backlog)
Fix when convenient. No immediate business impact.
When Severity and Priority Do Not Align
This is where it gets interesting and where many teams struggle.
High Severity, Low Priority
The bug is technically serious but affects a feature nobody uses or an edge case that almost never occurs.
Example: Application crashes when a user uploads a file exactly 2GB in size. The system limit is 1GB and the UI prevents uploads over 1GB. The crash exists but users cannot trigger it through normal use.
Decision: Log it, fix when convenient. The 1GB UI limit is the effective protection.
Low Severity, High Priority
The bug is technically minor but has significant business impact.
Example: The company CEO’s name is misspelled on the About page. Technically trivial (S4), but the CEO noticed and it is embarrassing during investor meetings. Priority: P1 — fix today.
Example: A competitor comparison page shows outdated pricing. No functional bug, but it causes lost sales. Low severity, high priority.
The Priority Matrix
| High Priority | Low Priority | |
|---|---|---|
| High Severity | Fix immediately (crash on login) | Fix in backlog (crash in unused admin tool) |
| Low Severity | Fix this sprint (CEO name typo) | Fix when convenient (extra whitespace) |
Who Sets What?
| Attribute | Set By | Based On |
|---|---|---|
| Severity | QA Engineer | Technical impact assessment |
| Priority | Product Owner / Manager | Business impact, deadlines, customer needs |
QA proposes both during bug reporting. Priority may be adjusted during triage meetings based on broader business context.
Exercise: Classify These Bugs
Assign severity (S1-S4) and priority (P1-P4) to each bug. Justify your choices.
- Mobile app crashes when rotating from portrait to landscape during video playback
- The “Terms of Service” link on the signup page leads to a 404 page
- Admin dashboard shows chart data one hour behind real-time (should be live)
- Email notifications use the old company logo (rebranding happened 2 months ago)
- Password reset token does not expire — remains valid indefinitely
Solution
1. App crash on rotation during video
- Severity: S2 (Major — crash, but only during specific action)
- Priority: P2 (High — affects user experience for video feature)
- Reasoning: Crashes are always at least S2, but the specific trigger (rotation during playback) limits impact
2. Terms of Service 404
- Severity: S3 (Minor — not core functionality)
- Priority: P1 (Immediate — legal compliance risk, all new users see signup page)
- Reasoning: Technically minor, but missing ToS could create legal liability
3. Dashboard data 1 hour behind
- Severity: S2 (Major — data accuracy issue in core feature)
- Priority: P2 (High — business decisions rely on dashboard data)
- Reasoning: Stale data could lead to wrong business decisions
4. Old logo in emails
- Severity: S4 (Trivial — cosmetic)
- Priority: P3 (Medium — brand consistency matters but not urgent after 2 months)
- Reasoning: If it was urgent, it would have been caught 2 months ago
5. Password reset token never expires
- Severity: S1 (Critical — security vulnerability)
- Priority: P1 (Immediate — active security risk)
- Reasoning: Non-expiring tokens mean anyone who intercepts a reset email can use it indefinitely. This is a critical security flaw.
Common Mistakes
- Treating severity and priority as the same — they measure different things
- QA setting priority unilaterally — priority is a business decision
- Inflating severity to get bugs fixed faster — erodes trust with developers
- Not re-evaluating priority over time — a P3 bug that persists for 6 months while users complain should be re-prioritized
Key Takeaways
- Severity measures technical impact (objective); priority measures business urgency (subjective)
- They are independent — a bug can be high severity/low priority or low severity/high priority
- QA assesses severity; Product Owner/Manager sets priority
- Priority is adjusted during triage meetings based on business context
- Never inflate severity to game the system — it destroys QA credibility