Severity vs Priority

Severity vs priority is the difference between how bad the failure is and how soon you will fix it. Mixing them is how a typo on the homepage jumps a checkout bug that only happens on one SKU.

Use both fields on every bug report. If your tracker has only one field, you are not recording both facts. You are recording a mood.

Severity (impact)

Severity describes the failure in the product, given the environment you tested.

Typical scale we actually use (names vary; the idea should not):

Severity	Meaning
Blocker / critical	Core journey dead, data loss, security exposure, cannot continue testing
Major	Important journey wrong; a workaround exists or the blast radius is limited
Minor	Incorrect but not on a money/auth/data path
Trivial	Cosmetic, copy, alignment — no functional miss

Severity is about the defect. It should not change because a VP is angry, and it should not drop because the release is Friday.

Priority (schedule)

Priority is a decision: when engineering will take it, relative to other work.

A critical severity bug can be low priority if it only happens on an OS you no longer support. A minor visual bug can be high priority if it is on a launch screenshot going to press at 9am.

Product and engineering set priority. QA recommends. If QA silently sets both to “critical / P1” on every ticket, the fields die.

Examples

Situation	Severity	Priority (typical)
Checkout 500s for all users on staging that matches prod	Critical	P1 — fix before anything else
Admin export CSV swaps two columns; finance uses it Monday	Major	P1 if Monday is real; else dated
Tooltip typo on a settings page	Trivial	P3 or a batch
Crash on an OS you dropped last year	Critical on that OS	Low if you do not ship that OS — say so

Write the environment. “Critical” with no device or build is a rumour.

What we will not do

• Invent a 17-point scoring matrix
• Treat ISTQB definitions as law if your tracker already has a working scale
• Raise severity to win an argument. Change the evidence.

This sits in the QA process after execution. It is also a QA metrics input: count open defects by severity, not as one pile.

FAQs

Who sets severity and who sets priority?

QA proposes severity from impact. Priority is a scheduling call — usually product or engineering. Argue with evidence, not with the word “blocker.”

Can priority be higher than severity?

Yes. A small defect on a launch asset can be first in the queue. Say why.

How do we start?

Use the bug report template. If every ticket is P1, book a consultation — the process is the defect.