Severity vs priority: a simple decision table for QA and developers
Almost every QA team argues about this at some point. A tester marks a bug as critical. A developer says it can wait. Both feel the other person does not understand.
Usually they are both right, because they are talking about two different things.
- Severity is how much damage the bug does.
- Priority is how soon we will fix it.
Once a team separates these two fields, the argument mostly disappears. This guide explains both in simple terms and gives you a table you can put on the wall.
Short version
- Severity is a fact about the bug. QA decides it.
- Priority is a business decision. The product owner or team lead decides it.
- A bug can be high severity and low priority (rare crash in an unused feature).
- A bug can be low severity and high priority (a typo in the company name on the homepage).
- Write both fields separately. Never merge them into one "urgency" field.
Severity in plain English
Severity answers one question: if this bug happens, how bad is it?
It does not care how often it happens, or how many users are affected, or whether the CEO noticed it. It only measures the damage of a single occurrence.
| Level | Name | What it means | Example |
|---|---|---|---|
| S1 | Critical | The system stops, or data is lost, or money is wrong | Payments charge twice |
| S2 | Major | A main feature does not work, and there is no workaround | Cannot upload any file |
| S3 | Minor | A feature works badly, but there is a workaround | Search is slow but works |
| S4 | Trivial | Cosmetic. Nothing is blocked | Button is 2px off centre |
The key test for S2 versus S3 is the workaround. If the user can still reach their goal another way, it is usually S3.
Priority in plain English
Priority answers a different question: when should we spend time on this?
That depends on things a tester often cannot see: the release date, the customer contract, the marketing campaign, the number of affected users, and how expensive the fix is.
| Level | Name | What it means | Typical target |
|---|---|---|---|
| P1 | Immediate | Stop other work and fix now | Same day |
| P2 | High | Must be in the next release | This sprint |
| P3 | Medium | Should be fixed soon | Next 1–2 sprints |
| P4 | Low | Fix when there is time | Backlog |
The difference in one sentence
Severity describes the bug. Priority describes our plan.
That is why the two fields are set by different people. QA is the expert on the bug. The product owner is the expert on the plan.
The four interesting combinations
Most teams understand "high severity, high priority" and "low severity, low priority". The learning happens in the other two corners.
High severity, high priority
The obvious case. Fix it now.
Example: the checkout page returns a 500 error for all users.
High severity, low priority
The bug does serious damage, but almost nobody will ever hit it.
Example: the app crashes if you set your device language to a language we do not support, and only 3 users have ever done that.
The crash is real and severe. But fixing it this week would mean delaying something that affects thousands of people. So: S1, P4.
Low severity, high priority
The damage is small, but it is very visible or embarrassing.
Example: the company name is spelled wrong in the page title on the homepage.
Nothing is broken. No data is lost. But it is on every page, it looks unprofessional, and it takes five minutes to fix. So: S4, P1.
Other examples in this corner: a wrong price shown in marketing copy, a broken logo, a legal disclaimer with a typo, an outdated year in the footer.
Low severity, low priority
Example: a tooltip appears 100ms slower than the design specifies.
Fine. Put it in the backlog. Most bugs live here, and that is healthy.
The decision table
Print this. Put it in your team wiki. Use it when people disagree.
| Affects everyone | Affects many | Affects few | Affects almost nobody | |
|---|---|---|---|---|
| S1 Critical | P1 | P1 | P2 | P3 |
| S2 Major | P1 | P2 | P2 | P3 |
| S3 Minor | P2 | P3 | P3 | P4 |
| S4 Trivial | P3 | P4 | P4 | P4 |
Then apply three override rules on top:
- Money or data loss is always P1, no matter how few users are affected.
- Security and privacy bugs are always P1 or P2, no matter how small they look.
- Legal and accessibility failures are at least P2, because they carry real risk beyond the product.
The table gets you 90% of the way. The overrides handle the rest.
How to write it in your bug report
Keep the two fields visible and separate:
Severity: S2 — Major (users cannot complete checkout with a saved card) Priority: proposed P1 Reason: Affects all returning customers. No workaround except re-entering card details.
Notice the word "proposed" next to priority. As a tester, you can suggest a priority, and you should. But the final call belongs to whoever owns the release. Making that explicit removes the tension.
Always add a one-line reason. "P1 because it affects all returning customers" is a fact people can discuss. "P1 because it is urgent" is not.
Common mistakes
Using one field for both. Many teams have a single "Priority" dropdown and use it for everything. This is why arguments happen. Add a severity field. It costs nothing.
Marking everything critical. If half your bugs are S1, then nothing is S1. Teams learn to ignore the label, and a real emergency gets missed.
Letting severity drift with mood. Severity should be the same on Monday and Friday. If a bug feels more severe because a customer complained loudly, that is a priority change, not a severity change.
Never revisiting priority. Priority changes as the business changes. A P4 bug becomes P1 the week before a big customer demo. That is normal — review the list regularly.
Testers setting priority alone. It feels efficient, but it removes the product owner from a business decision. It also puts testers in a difficult position when they are wrong.
Who decides what
| Field | Owner | Input from |
|---|---|---|
| Severity | QA / the person who found the bug | Developer, if the technical impact is unclear |
| Priority | Product owner or team lead | QA, support, sales, engineering |
| Reason | Whoever sets the field | Everyone |
Give people clear ownership and the debates get much shorter.
Making the severity call faster
Most of the time, severity is easy to judge if the report contains good evidence. Does data disappear? Does the page fail completely? Is money involved? A screenshot, the console errors, and the failed network request usually answer all three in seconds.
If your reports arrive without that evidence, severity becomes guesswork. Capturing it automatically — which is what tools like Crosscheck do when a bug is reported straight from the page — removes most of the guessing from triage.
Frequently asked questions
Can a bug be S1 and P4 forever? Yes, and that is fine, as long as it is a real decision and it is written down. Review those bugs every few months.
Should the customer decide priority? Customer impact is a strong input to priority, but the decision has to balance all customers and the release plan. So: their voice counts, but the product owner decides.
How many severity levels should we have? Four is enough for almost every team. Five is manageable. More than five and people stop being able to tell the middle levels apart.
What about "blocker"? "Blocker" usually means a bug that stops testing from continuing. That is a useful separate flag, not a severity level. A blocker can be any severity.
Do we need both fields on small teams? Yes, and small teams benefit most. When one person wears several hats, writing the fields down keeps the two questions from blurring together.
Add to Chrome