Severity vs Priority
These are independent axes. A bug can be high severity but low priority, or low severity but high priority. Confusing the two is one of the most common mistakes QA engineers make, and it leads to mismanaged backlogs, frustrated developers, and missed deadlines.
Definitions
Severity
Severity measures the technical impact of the defect. How badly does it damage functionality? Severity is a factual observation about what the bug does to the system.
| Level | Definition | Example |
|---|---|---|
| Critical | System crash, data loss, security breach, complete feature failure | Application crashes on checkout for all users |
| High | Major feature broken, no workaround | Payment fails for credit cards but works for PayPal |
| Medium | Feature partially broken, workaround exists | Search returns results but sorting does not work |
| Low | Cosmetic issue, minor inconvenience | Button alignment off by 2 pixels on one page |
Priority
Priority measures the business urgency of fixing the defect. How soon must this be fixed? Priority is a business decision about scheduling.
| Level | Definition | Example |
|---|---|---|
| P0 | Fix immediately, drop everything | Production is down |
| P1 | Fix within 24 hours | Critical flow broken for a subset of users |
| P2 | Fix this sprint | Important but not blocking |
| P3 | Fix eventually | Nice to have, low user impact |
The Two-Axis Matrix
| High Priority | Low Priority | |
|---|---|---|
| High Severity | App crashes on checkout for all users — fix now | App crashes when entering 10,000-character name — rare edge case, fix in next sprint |
| Low Severity | CEO's name is misspelled on the homepage — cosmetic but urgent | Footer link color is slightly off-brand — fix eventually |
Analyzing Each Quadrant
High Severity + High Priority (top-left): The obvious emergencies. Production is down, users are losing data, security is breached. Everyone agrees these get fixed immediately.
High Severity + Low Priority (top-right): Severe bugs that rarely occur. A crash that only happens with a 10,000-character input is technically critical but affects almost nobody. Schedule the fix, but do not interrupt the current sprint.
Low Severity + High Priority (bottom-left): Cosmetic or minor issues with outsized business impact. The CEO's name misspelled on the homepage is a trivial bug, but it needs to be fixed before the board meeting tomorrow. A broken link on a campaign landing page during a marketing push.
Low Severity + Low Priority (bottom-right): The backlog inhabitants. Minor visual issues, edge-case formatting problems, improvement suggestions. These get fixed when there is bandwidth, or during dedicated cleanup sprints.
Who Decides?
Severity: QA Assesses
Severity is a factual observation about the bug's technical impact. The QA engineer who found and reproduced the bug is best positioned to assess it.
When assessing severity, ask:
- Does the bug crash the application or corrupt data? (Critical)
- Does it prevent a user from completing a core workflow? (High)
- Does it degrade functionality but allow workarounds? (Medium)
- Is it cosmetic or affects only edge cases? (Low)
Priority: Product/Engineering Management Decides
Priority is a business decision that considers factors beyond the bug itself:
- How many users are affected?
- Is there a regulatory deadline?
- Is there a major customer affected?
- Is a marketing campaign depending on this feature?
- What is the opportunity cost of fixing this now vs later?
When QA and Management Disagree
Sometimes QA rates a bug as Critical severity, but the product owner sets priority to P2. This happens when:
- The bug is severe but affects very few users
- The team has higher-priority work (launch deadline)
- A workaround exists that mitigates the impact
This is normal. QA's job is to accurately report severity. Management's job is to prioritize the backlog. QA should advocate for the fix but respect the prioritization decision — unless it involves data loss, security, or compliance, in which case escalate.
Common Mistakes
1. Using "Severity" When You Mean "Priority"
"This is a severity 1 bug, fix it now!"
Severity 1 means the bug is technically devastating. Whether to fix it now depends on priority, which depends on business context. A severity 1 bug in a feature used by 3 internal users may be P2.
2. Inflating Severity to Get Attention
Marking every bug as "Critical" to ensure it gets fixed is counterproductive. When everything is critical, nothing is critical. The team stops trusting severity ratings, and truly critical bugs get lost in the noise.
3. Using a Single Scale
Some teams use only one field ("High/Medium/Low") for both severity and priority. This forces trade-offs that obscure information. A bug can be simultaneously "high severity" and "low priority" — a single scale cannot represent this.
4. Never Updating Priority
A P3 bug filed three months ago may now be P1 because a major customer complained about it. Priority should be reassessed during triage meetings.
Severity/Priority in Bug Tracking Tools
Jira Configuration
Jira has separate "Priority" and "Severity" fields (severity must be added as a custom field). Use both:
- Priority: Blocker / Critical / Major / Minor / Trivial
- Severity (custom): Critical / High / Medium / Low
GitHub Issues
Use labels to represent both dimensions:
severity:critical,severity:high,severity:medium,severity:lowpriority:p0,priority:p1,priority:p2,priority:p3
Linear
Linear's built-in priority (Urgent / High / Medium / Low / No priority) maps to priority. Add a "Severity" label group for the second dimension.
Triage Meetings
Bug triage is the regular meeting where the team reviews new bugs and assigns priority. Effective triage:
- QA presents the bug with severity assessment
- Product owner assesses business impact and sets priority
- Engineering estimates effort to fix
- Team decides: fix now, schedule for this sprint, or add to backlog
Triage Questions
- Who is affected? (All users, subset, internal only?)
- Is there a workaround? (If yes, priority may decrease)
- What is the blast radius? (One feature, multiple features, entire app?)
- Is this a regression? (Regressions often get higher priority because they broke something that was working)
- Is there a compliance or security implication? (Automatic priority escalation)
Practical Exercise
For each of the following bugs, assign both a severity level and a priority level, and justify your choices:
- The "Forgot Password" email link points to the wrong URL — users cannot reset passwords
- The admin dashboard shows the wrong time zone for log timestamps
- A SQL injection vulnerability is discovered in the search bar
- The mobile app crashes when the user rotates the screen during video playback
- The company logo on the login page is the old version from the 2023 rebrand
Key Takeaways
- Severity is technical impact (assessed by QA). Priority is business urgency (set by product/management).
- Keep them as separate fields in your bug tracker — never collapse into one scale
- High severity does not automatically mean high priority, and vice versa
- A QA engineer who conflates severity and priority will misprioritize the backlog
- Triage meetings are where severity meets priority — present your findings clearly and let the team decide
Interview Talking Point: "I treat manual testing as a thinking discipline, not a task to automate away. I use session-based exploratory testing with charters and time boxes to systematically find issues that scripted tests miss. When I file a bug, I include a minimal reproduction, environment details, and a clear severity/priority split — because a bug report that a developer can reproduce in under two minutes gets fixed in hours, not weeks."