Severity vs Priority

“What is the difference between severity and priority? Give an example of high severity, low priority.” It is one of the most frequently asked QA interview questions, and it matters in daily work too: every defect that enters the bug lifecycle gets both values at triage, and those values decide what gets fixed before release.

The short version: severity is about the system, priority is about the business.

Definitions

Severity is the degree of impact a defect has on the operation of the system or component. It answers: how bad is the damage when this happens? It is a mostly technical judgement, based on what breaks, whether data is affected, and whether there is a workaround.

Priority is the business importance of fixing the defect, which translates into how soon it should be fixed. It depends on context that the tester often does not fully have: how many users hit it, release dates, contracts, brand visibility, revenue, the cost and risk of the fix.

	Severity	Priority
Question it answers	How much damage does it do?	How soon must we fix it?
Based on	Technical impact, workaround, data, security	Business impact, reach, deadlines, cost of fixing
Usually proposed by	Tester (reporter)	Product owner or triage group
Changes over time?	Rarely; the impact is what it is	Often; a launch or a customer escalation can raise it
Typical scale	Blocker, Critical, Major, Minor, Trivial	P1 Highest, P2 High, P3 Medium, P4 Low

The scales vary between organisations and tools. Jira’s default field, for example, is a single “Priority” with no separate severity field, so many teams add a custom severity field. What matters is that your team agrees what each level means.

Severity levels

The scale used on this site, and in the Bug Severity and Priority tool:

Severity	Definition	Example
Blocker	Stops testing or use of the product entirely. No workaround.	App crashes on launch; sign-in returns HTTP 500 for every user
Critical	A core function fails, data is lost or corrupted, or there is a security or privacy breach. No acceptable workaround.	Customers are charged twice; one user can read another user’s invoices
Major	A significant function does not work as specified, but there is a workaround or the impact is limited to part of the feature.	Search ignores the date filter; export fails over 10 MB but smaller exports work
Minor	Behaviour is wrong but the function is usable.	Error says “Invalid input” without naming the field; wrong default sort order
Trivial	Cosmetic, no functional impact.	A settings dialog button is 2px out of alignment

Two questions get you most of the way: what is the impact (crash, data, security, core feature, partial feature, cosmetic) and is there a workaround (none, awkward, easy)?

Priority levels

Priority	Meaning
P1 Highest	Fix now. A hotfix, or it blocks the release; someone starts today.
P2 High	Fix in the current sprint or release before shipping.
P3 Medium	Fix in a planned upcoming release.
P4 Low	Fix when convenient; may be batched or deferred to the backlog.

Priority is driven by reach (how many users are affected) and visibility or urgency for the business (release-blocking, legal or contractual, revenue, brand, or internal only).

The four quadrants

Interviewers love these because they prove you understand that the two values are independent.

High severity, high priority

The obvious case: serious damage that many people will hit.

• Checkout fails with a 500 error for all card payments.
• Users can see other customers’ order history.
• App crashes on launch on the most-used Android version.

High severity, low priority

Serious damage, but very few people can reach it, or it is not reachable yet.

• Report export crashes the app, but only on a legacy browser used by a tiny fraction of users.
• Data corruption in a feature behind a feature flag that is switched off.
• Crash when importing a 2 GB file when the documented limit is 50 MB.

These are still real defects with high severity. Low priority means “schedule it sensibly”, not “ignore it”. Record them so the risk is visible.

Low severity, high priority

Small technical impact, but the business needs it fixed now.

• Company name misspelled in the homepage header.
• Wrong price shown in a launch-day marketing banner, although checkout charges correctly.
• A partner logo missing from a page that a contract requires.

Nothing is functionally broken, yet each of these is embarrassing, visible to everyone, or has legal or commercial consequences.

Low severity, low priority

Small and rarely seen.

• Tooltip text misaligned by a few pixels in an admin settings page.
• Inconsistent capitalisation in a rarely used dialog.
• Footer link hover colour differs from the design.

Worked triage examples

Defect	Severity	Priority	Reasoning
Password reset emails are not sent for any user	Critical	P1 Highest	Core function broken for everyone; support-desk workaround is not acceptable at scale
PDF invoice shows the wrong VAT number	Minor	P2 High	Invoice is usable, but it is a legal document; must be correct before the next billing run
App crashes when the device language is set to a language you do not support	Critical	P3 Medium	Crash with no workaround for those users, but very few users can reach it; fix in a planned release
Search results load in 4 seconds instead of the target of 1 second	Major	P2 High	Feature works but noticeably degraded for everyone
Typo in an internal admin audit log label	Trivial	P4 Low	Cosmetic and internal

Notice the third row: high severity and medium priority is a normal, defensible result. Severity was not lowered to match the priority.

Common mistakes

• Setting priority equal to severity by default. They are different questions with different owners; they often have different answers.
• Inflating severity to get a bug fixed sooner. It erodes trust in your reports. If you think something should be fixed sooner, argue for priority with the business reason: “this appears on the pricing page during the launch campaign”.
• Rating a crash as Critical without checking reach, then being surprised it is not P1. Severity can be high while priority stays low when few users can hit the problem.
• Treating all visual issues as Trivial. A layout problem that hides the Buy button is a functional defect.
• Never revisiting priority. A low-priority bug can become urgent when a customer escalates or a launch date approaches.
• Leaving security and data-loss bugs at a default severity. Treat them as at least Critical until someone with context decides otherwise.

How this fits into a release decision

Exit criteria often reference severity: “no open Blocker or Critical defects”. This works only if severity is honest. If a Critical defect is accepted for release, for example because the affected feature is switched off, the decision should be recorded with its reason. That is far better than downgrading the severity so the criterion is technically met.

Practice exercise

Assign a severity (Blocker, Critical, Major, Minor, Trivial) and a priority (P1 to P4) to each defect in an online grocery app, and justify each in one sentence. Then check your thinking with the Bug Severity and Priority tool.

1. Delivery slot picker shows slots in UTC instead of local time; customers book the wrong hour.
2. “Remember me” checkbox on login does nothing; users must log in each visit.
3. The app crashes when a user adds the 1,000th item to a single basket.
4. The store’s name is misspelled on the app store listing screenshot used for a launch next week.
5. Loyalty points are credited twice for orders paid with a gift card.

Show a model answer

#	Severity	Priority	Reasoning
1	Critical	P1 Highest	Core function (booking delivery) produces wrong outcomes for every customer outside UTC; no reasonable workaround
2	Minor	P3 Medium	Annoying but the function (logging in) still works; fix in a planned release
3	Critical	P4 Low or P3 Medium	A crash with no workaround, but almost no real basket reaches that size; record it and schedule it
4	Trivial	P1 Highest or P2 High	No functional impact, but it is highly visible and tied to a fixed launch date
5	Critical	P2 High	Data integrity problem with financial value; affects only gift-card orders, so it may not need a hotfix today, but must be fixed before it accumulates further

Reasonable people can differ by one level, especially on priority, because it depends on business context. What matters is that each value is justified by impact and workaround (severity) or reach and urgency (priority), and that the two are assessed separately.

Key takeaways

• Severity is the impact on the system; priority is how soon the business wants it fixed.
• Testers usually propose severity; product owners or triage groups decide priority.
• All four combinations are normal. Be ready with examples and reasons for each quadrant.
• Never inflate severity to influence priority; argue for priority with business evidence instead.
• Revisit priority as context changes; keep severity honest so exit criteria mean something.