Bug reporting
Severity vs. priority
Severity is the degree of impact a defect has on the system; priority is how soon the team should fix it.
The two are independent: a cosmetic bug can be urgent before a launch, and a crash in a rarely used screen can wait. Triage judges severity from the report; whoever owns the backlog sets priority.
At a glance
| Severity | Priority | |
|---|---|---|
| Answers | How much damage does this do? | How soon do we fix it? |
| ISTQB definition | "The degree of impact that a defect has on the development, testing or operation of a component or system" (ISTQB) | "The level of importance assigned to a task according to specific criteria" (ISTQB) |
| Decided by | The bug itself: data loss, blocked workflows, how many people hit it, whether a workaround exists | The business: release dates, who is affected, what else is queued |
| Who sets it | Triage, from the report. Bugzilla asks people filing bugs not to set it (Bugzilla) | The product or engineering owner of the backlog |
| Bugzilla scale | S1 Catastrophic, S2 Serious, S3 Normal, S4 Small/Trivial | P1 current release cycle, P2 the next one or two, P3 backlog, P5 will not fix |
| Changes when | The bug or the system changes | The schedule or the roadmap changes |
Why it matters
When one field has to carry both ideas, every bug drifts toward "high" and the field stops sorting anything. Severity describes the defect and barely changes; priority is a scheduling decision that moves with the release calendar. Bugzilla keeps them separate for exactly that reason: severity is "used as input for the priority of the bug", and it is set by triage rather than by the person filing it (Bugzilla).
Severity and priority examples
| Bug | Severity / priority | Why |
|---|---|---|
| Checkout fails for every customer | S1 / P1 | Revenue has stopped and there is no workaround |
| Wrong price on the pricing page, launch tomorrow | S4 cosmetic / P1 | Trivial to fix, costly to ship |
| Crash in a report only finance opens at quarter end | S1 / P3 until the quarter nears | Severe, but nobody meets it this week |
| Hover color slightly off-brand on a footer link | S4 / P3 backlog | Nobody is blocked |
Common mistakes
- One field for both. "High" then means urgent to one person and damaging to another, and the list stops sorting.
- Letting the reporter set severity. Bugzilla asks filers to leave it at the default so triage can judge it from the report with the whole product in view.
- Filing everything as the top priority. Priority is relative. If every bug is P1, the field carries no information.
- Ignoring the workaround. Bugzilla's S3 is "blocks non-critical functionality or a workaround exists"; a bug with a workaround is rarely S1 or S2.
- Never revisiting priority. A P3 before a launch can be a P1 the week after a customer meets it. Severity stays put; priority is re-read at every planning pass.
Frequently asked questions
Can a bug have high severity and low priority?
Yes. A crash in a screen one team opens once a quarter is severe, since work or data is lost, and still low priority until that quarter end approaches. The reverse is just as common: a typo in a headline is cosmetic and urgent the day before a launch.
Who should set severity and who should set priority?
Severity is judged from the report by whoever triages the bug; Bugzilla asks the person filing it to leave the field at its default. Priority is set by the owner of the backlog, with severity as one input alongside dates, affected users and what else is queued.
What are the Bugzilla severity levels?
S1 Catastrophic: blocks development or testing, may affect more than 25% of users, causes data loss, and has no workaround. S2 Serious: major functionality severely impaired with no satisfactory workaround. S3 Normal: blocks non-critical functionality or a workaround exists. S4 Small or trivial: cosmetic, with low or no impact.
What are the Bugzilla priority levels?
P1 is fixed in the current release cycle, P2 in the next cycle or the one after, P3 is the backlog, and P5 will not be fixed although a patch would be accepted. P4 is reserved for an automated test bot and is not used by hand.
Sources: ISTQB Glossary, severity, ISTQB Glossary, priority, Bugzilla, Bug Fields.
Last updated October 22, 2026