Bug Severity vs Priority: How to Set Both

Severity describes how bad a bug’s effect is: data lost, a main task blocked, a workaround available, or a cosmetic fault. Priority is the team’s decision about when to fix it, weighed against everything else waiting. The reporter or tester proposes severity from what they saw; whoever orders the team’s work sets priority. Most of the time the two move together. The cases worth thinking about are where they do not: a severe bug that can wait, and a trivial one that must be fixed today. Below are the definitions, a matrix with examples in each corner, who sets which, the usual mistakes, and how to map it all onto a 1 to 10 priority.

Writing the report itself, with steps, environment and evidence, is covered in the bug report template. This page picks up where its short “severity is not priority” section stops.

The definitions

The ISTQB glossary, the standard vocabulary for software testers, defines severity↗ (opens in a new tab) as the degree of impact that a defect has on the development, testing or operation of a component or system, and priority as the level of importance assigned to a task according to specific criteria. One is a measurement of the bug; the other is a judgement about the work.

Mozilla publishes a clear, public example of both scales. Its Bugzilla field definitions↗ (opens in a new tab) give four 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, or a high-impact problem with no satisfactory workaround.
• S3, normal: blocks non-critical functionality, or a workaround exists.
• S4, small or trivial: minor significance, cosmetic, low or no impact on users.

Its priority scale↗ (opens in a new tab) is about timing, not effect: P1 means fix in the current release cycle, P2 in the next one or the one after, P3 is the backlog, and P5 means it will not be fixed by the team but a patch would be accepted. (P4 is reserved for a test bot.) New bugs start with no severity and no priority until someone triages them.

Two questions, different evidence

Severity answers “what happens to someone who hits this?” It comes from facts in the report: what breaks, whether data is lost or wrong, how many people are affected, and whether there is a workaround. Two people looking at the same evidence should arrive at the same severity.

Priority answers “what do we do first?” It takes severity as one input and adds things the reporter usually cannot see: how many customers actually use that path, what is being released next week, a contract or a launch date, how long the fix will take, and what else is waiting. Two people can reasonably disagree about priority, which is why one named person decides it.

The matrix, with examples

                    LOW PRIORITY              HIGH PRIORITY
HIGH SEVERITY   Bad, but rare or ending   Bad, and happening now
                -> schedule, note why     -> fix first
LOW SEVERITY    Minor and out of sight    Minor, but in plain view
                -> batch, or close        -> fix soon, it is cheap

• High severity, high priority. Every card payment fails at checkout. Saving a form silently loses the text. The sign-in page is down. Nobody needs a meeting for these.
• High severity, low priority. The app crashes on an operating system version that almost none of your customers still use. A yearly import corrupts one field, the next run is eleven months away, and the data can be fixed by hand meanwhile. A crash in a feature being removed next month. Severe for whoever hits it, but other work helps more people sooner. Write down why it is waiting.
• Low severity, high priority. A misspelt company name in the headline of the page tomorrow’s campaign points at. The wrong logo for a partner whose contract requires theirs. A confusing label on the one screen every new customer sees. Cosmetic in effect, but visible, cheap to fix and costly to leave.
• Low severity, low priority. An icon one pixel out of line on one screen size. Awkward wording in a tooltip in an admin screen. Batch these, fix them when someone is in that code anyway, and close the ones that stop mattering.

Who sets which

1. The reporter describes the effect in plain words and proposes a severity. A customer does not need to know S1 from S2; “I lost everything I typed” is enough for someone else to set it.
2. Triage confirms severity. Someone who knows the product checks the evidence, tries to reproduce it and sets the severity. Mozilla’s triage guidelines↗ (opens in a new tab) give this job to a named triage owner per component, say priority can but need not be set at the same time, and expect new bugs to be fully triaged or under investigation within a week.
3. The person who orders the work sets priority. In Scrum that is the Product Owner; in a small team it is whoever decides what happens next. One person, so that priority means one thing.
4. The person fixing it can challenge either, with evidence. If the fix turns out to be a day’s work instead of an hour’s, priority may change; if it affects more users than the report said, severity should.

Common mistakes

• One field for both. A single “urgency” field forces the reporter to guess at the team’s plans and the planner to overwrite the reporter’s evidence. Keep them apart, even if severity is only a line in the description.
• Reporters setting priority. Every reporter’s bug is urgent to them. If the form asks for priority, most answers will be “high” and the field stops meaning anything.
• Inflating severity to get attention. When the only way to be heard is to say S1, everything becomes S1. Keep severity tied to the written definitions and give reporters another way to be heard: a comment, a reply, a named person.
• Priority set once and never revisited. The launch passes, the contract ends, the feature is retired. Review the top of the list at each triage and let priorities fall as well as rise.
• Too many at the top. If a dozen open bugs are P1, none of them is. The top level should hold what someone is working on now.
• Never closing the low corner. A pile of S4 bugs nobody will fix is noise. Close them with a reason, or batch them into one piece of work.
• Treating severity as fixed. New evidence, such as more affected users or data loss discovered later, should change it, and the change should be recorded.

Mapping onto a 1 to 10 priority

Many boards, fenbs included, use a single priority number from 1 to 10, with 1 the most urgent. Ten steps leave room between “drop everything” and “this week”. A starting map from severity, which triage then adjusts for the things severity does not know:

S1 catastrophic  -> P1        someone starts now
S2 serious       -> P2 to P3  this week, or the next release
S3 normal        -> P4 to P6  in order with other work
S4 trivial       -> P7 to P10 when someone is nearby, or close it

Then adjust: visible to every new customer, or tied to a date -> up.
Rare path, retiring feature, cheap workaround               -> down.
Record the reason in a comment whenever you move it more than two steps.

Resist using P10 as a place to leave things forever. Mozilla’s P5, “will not fix, but will accept a patch”, is an honest answer; so is closing the bug with a reason. A bug that has sat at the bottom for a year is a decision nobody has written down.

Severity and priority on a fenbs board

On fenbs a bug is a task of kind bug, with a ref such as BUG-046. Priority is a field from 1 to 10, 1 the most urgent and P5 by default, and the board groups it into bands you can filter by: High is P1 to P2, Medium P3 to P5, Low P6 to P10. There is no separate severity field and there will not be one, so put severity as the first line of the task’s note, where it is written once and kept: Severity: S2, export fails for all accounts over 10,000 rows; workaround: filter by month.

• Reporters file, triage decides. Give testers and customers the suggested Reporter role: they can add tasks and comment, edit only their own, and cannot move tasks between lanes. The person who orders the work sets the priority and moves bugs into Next Up.
• An AI assistant can help triage. Connected over MCP, it can read new bugs, try to reproduce them, and comment with a proposed severity and priority and the reason. Keep the final priority with a person; the assistant’s comment and the person’s change both appear in the task’s history under their own names.
• Closing the low corner has a place. When a bug is moved to Completed you choose how it ended: Completed, Won’t fix, Duplicate, Cannot reproduce or Obsolete. Only Completed counts as delivered, so closing S4 bugs as Won’t fix does not flatter the board’s figures.