QA Process
Bug Severity vs Priority.
Severity is how badly something is broken; priority is how soon to fix it. This guide shows the difference, the levels, and worked examples — including the cases where the two disagree.
When to use it
Use this when you're logging or triaging a defect and need to set severity and priority correctly, or when an interviewer asks you to explain the difference. It's also the reference to point to when a team keeps conflating the two fields.
Who uses it
QA engineers setting severity on the defects they raise, product owners setting priority, and triage teams reconciling the two — plus candidates prepping for QA interviews.
On this page11 sections
WHAT IS SEVERITY
Severity describes how badly a defect damages the product when it occurs — the technical impact, independent of how many people hit it or when. A crash, lost data, or a blocked core flow is high severity; a cosmetic glitch is low severity.
Severity is meant to be an objective judgement: given that this defect happens, how much does it hurt? You answer it from the product's behaviour, not from the calendar or the roadmap. That's what keeps it separate from priority.
WHAT IS PRIORITY
Priority describes how soon a defect should be fixed relative to everything else. It's a business decision driven by urgency: release timing, customer commitments, how visible the issue is, and what else the team could be doing instead.
Because it weighs the defect against other work, priority can change without the defect itself changing. The same bug can be "fix it today" the week before a launch and "backlog" the week after.
SEVERITY VS PRIORITY DIFFERENCE
| Severity | Priority | |
|---|---|---|
| Measures | How badly it breaks | How soon to fix it |
| Driven by | Technical impact | Business urgency |
| Set by | QA / tester | Product owner / business |
| Changes when | The defect's effect changes | Timing or priorities shift |
| Example | A crash is high severity | A pre-launch typo is high priority |
SEVERITY LEVELS
Most teams use four severity levels. The labels matter less than a shared, written definition of each — that's what stops every defect from being argued up to "Critical".
Critical
The product is unusable or losing/exposing data: a crash, a down service, a broken payment path, or a security hole. No acceptable workaround.
High
A major feature is broken or behaves wrongly, but the rest of the product works and there may be an awkward workaround.
Medium
A feature works but with a noticeable defect or only in a limited scenario — a validation gap, a wrong message, an edge-case failure.
Low
Cosmetic or trivial: minor visual misalignment, a typo, inconsistent spacing. Nothing functional is affected.
PRIORITY LEVELS
Priority is usually a short ordered scale. Three or four levels is plenty — more just invites debate about the middle.
P1 — Urgent
Fix immediately; it blocks a release, a customer, or the team. Work stops or reorders around it.
P2 — High
Fix in the current cycle. Important, but it doesn't have to be solved this hour.
P3 — Normal / Low
Schedule it when there's room. Goes to the backlog with a clear note so it isn't lost.
EXAMPLES BY CATEGORY
| Scenario | Severity | Priority | Why |
|---|---|---|---|
| Payment is failing for all users | Critical | P1 | Business-critical flow broken |
| Logo is slightly misaligned | Low | P3 | Cosmetic issue |
| Terms typo on homepage | Low | P1 | Important if launch is today |
| Admin can access another user's data | Critical | P1 | Security and privacy risk |
| Rare browser layout issue | Medium | P3 | Limited user impact |
WHO DECIDES SEVERITY
QA usually sets severity, because it's a technical read on impact made from the tester's seat: does it crash, lose data, block a flow, or just look slightly off? Engineering may adjust it once the root cause is understood.
Keep it honest. Inflating severity to force attention erodes trust in the field — and the moment leadership stops believing your "Critical", the whole scale stops working.
WHO DECIDES PRIORITY
Priority is the product owner's or business's call, because it weighs the defect against release timing, customer impact, and everything else competing for the team's time. In practice it's often agreed in triage with QA and engineering in the room.
QA's job is to give priority-setters what they need: clear impact, who's affected, and whether there's a workaround. You inform priority; you don't usually own it.
COMMON MISTAKES
Treating severity and priority as the same field.
Keep them separate. A low-severity typo can be high priority before a launch; a high-severity admin crash can be low priority if almost no one hits it.
Marking everything Critical to get it noticed.
Reserve Critical for unusable / data-loss / security. Over-using it trains people to ignore your severities.
QA setting priority unilaterally.
Surface impact and a recommendation, but let the product owner own the priority. It depends on business context you may not have.
No written definition for each level.
Agree one-line definitions for each severity and priority level. Without them, every defect becomes a negotiation.
Never revisiting priority as context changes.
Priority is relative to timing. Re-check it at triage — what was P3 last sprint may be P1 the week of release.
INTERVIEW ANSWER
If an interviewer asks for the difference, here's an answer that lands: "Severity is about how badly something is broken — the technical impact — and priority is about how soon we need to fix it — the business urgency. They usually move together, but not always."
"A typo on the homepage is low severity because nothing is actually broken, but if we're launching today it can be high priority because it's the first thing customers see. It works the other way too: a crash in a rarely-used admin export might be high severity but low priority because almost no one hits it."
"In practice I set severity from the tester's seat based on impact, and I expect the product owner to set priority based on business need. When they disagree, that's a conversation in triage — not a number I quietly change on my own."