Severity vs Priority in Software Testing: Differences, Matrix & Examples
Severity measures the technical impact of a defect; priority measures how soon it must be fixed. Learn the four combinations with a matrix, real examples, and who sets each in 2026.
Last updated: July 11, 2026 · 7 min read
Severity vs priority is one of the most-asked QA interview questions — and one of the most-confused concepts on real teams. This guide gives you sharp definitions, a matrix, and worked examples.
Definitions
Severity — the technical impact of a defect on the system. Objective. Set by QA.
Priority — how urgently the defect must be fixed relative to other work. Business-driven. Set by PM / Product Owner.
The typical levels
| Severity | Meaning |
|---|---|
| Critical / S1 | System crash, data loss, blocker |
| High / S2 | Major feature broken, no workaround |
| Medium / S3 | Feature works with acceptable workaround |
| Low / S4 | Cosmetic issue, minor UX |
| Priority | Meaning |
|---|---|
| P1 | Fix immediately, hotfix |
| P2 | Fix in current sprint |
| P3 | Fix in next release |
| P4 | Backlog / when convenient |
The 4-quadrant matrix
| High priority | Low priority | |
|---|---|---|
| High severity | Payment page crashes — fix now | Legacy admin page crashes; used by 2 users/year |
| Low severity | Company logo wrong on homepage the day before a keynote | Typo in a rarely-visited footer link |
The mismatched quadrants are the interesting ones — high sev / low pri and low sev / high pri — because they show that severity alone can't drive scheduling.
Real examples
- High severity, high priority: checkout API returns 500 for 30% of requests.
- High severity, low priority: data-export crashes for accounts > 10M rows (2 customers affected, workaround: chunked export).
- Low severity, high priority: misspelled CEO name on the About page before a press release.
- Low severity, low priority: footer copyright still says 2024.
Who sets severity vs priority?
- Severity — QA engineer at defect logging. It's technical and objective.
- Priority — PM / Product Owner at triage. It's business-driven and negotiable.
- Both can be adjusted at the daily bug triage meeting when new context arrives.
How to answer in an interview
"Severity is the technical damage the defect causes to the system — I set it as QA. Priority is how urgently business wants it fixed — the PM sets it. They're independent: a small typo on the homepage before a launch is low severity but high priority; a crash in a rarely-used admin export is high severity but low priority."
Continue your learning
Severity + Priority: the 4-quadrant defect triage matrix (2026)
Every mature bug tracker — Jira, Linear, GitHub Issues with labels — needs both severity and priority because they answer different questions. Plotting them on a 2x2 gives you an unambiguous triage rule your team can automate:
| High Priority | Low Priority | |
|---|---|---|
| High Severity | P0 — fix now. Payment button crashes at checkout. | P2 — schedule. Data-export crashes for a report used once a quarter. |
| Low Severity | P1 — fix this sprint. Company logo missing on the homepage during a rebrand. | P3 — backlog. Typo on a rarely visited help article. |
Two rules that stop 90% of triage arguments:
- QA sets severity, PM sets priority. Severity is a technical assessment (blast radius, data loss, revenue impact). Priority is a business decision (customer impact, release proximity, competitive risk).
- Every ticket carries both fields. A ticket with only severity leaves engineering guessing when to fix it. A ticket with only priority leaves the release manager guessing how bad it is.
Real triage example — day one after a launch
Three bugs land in the queue at 09:00:
- Bug A: Checkout returns HTTP 500 for orders over $1,000 (1% of traffic, blocks revenue). Severity: Critical. Priority: P0. Rollback or hotfix within 2 hours.
- Bug B: Marketing hero image does not load on iOS Safari 17 (visible to 100% of iPhone visitors). Severity: Low (functional path works). Priority: P1. Ship a fix in the daily deploy.
- Bug C: Admin CSV export crashes for datasets over 50k rows (used by 3 internal users). Severity: High (blocks a critical internal workflow). Priority: P2. Schedule for next sprint with a manual workaround documented.
Notice how a low-severity bug (B) can outrank a high-severity one (C) on priority. That is the point of two axes.
Interview-ready one-liner
Severity is how badly it breaks the system; priority is how quickly the business wants it fixed. They correlate but are not identical — a typo on the homepage is low severity, high priority; a crash in a monthly report is high severity, low priority.