Severity vs Priority: What to Do When Testers and the Business Disagree

A tester logs a bug an hour before a release freeze. The checkout button's label is misaligned by three pixels on Safari. Nobody's data is at risk, nothing crashes, the order still goes through. The tester marks it low severity, because objectively that's what it is. Then the product manager reads the ticket and marks it top priority, because the release goes to 40,000 customers tomorrow and someone will screenshot that button before lunch. Now there's a meeting. This happens on most teams at least once a quarter, and it usually happens badly, because nobody wrote down who actually gets to decide which number wins.

What severity and priority actually mean

Severity is a measurement. It describes how badly the defect breaks the product, judged against the code and the system, not against the calendar. A crash on checkout is high severity. A misspelled word in a footer is low severity. Severity doesn't change if the release date moves.

Priority is a scheduling decision. It describes how soon the defect needs fixing relative to everything else competing for the same developers' time this week. Priority changes constantly, because it depends on what else is happening: a launch, a customer contract, a compliance deadline.

Because these are two different questions, a defect can land anywhere on a grid of the two:

| | High severity | Low severity |
|---|---|---|
| High priority | Payment processing fails for all users on a Friday launch. Fix now, no debate. | The Safari checkout button misalignment before a big campaign. Small break, urgent optics. |
| Low priority | A rare crash in an admin tool used by two internal staff, once a month. Serious but not urgent. | A typo in a help article nobody has read yet. Neither urgent nor damaging. |

Three of those quadrants are easy. Nobody argues about a payment outage or a stray typo. The fourth one, high priority and low severity, is where every real disagreement happens.

The quadrant where the argument lives

High severity, low priority defects mostly get ignored quietly, which is its own problem but rarely a fight. It's the high priority, low severity cell that causes tension, because it looks like it shouldn't matter and yet somebody with authority insists it does. A support team escalates a cosmetic bug because ten customers tweeted about it. A sales lead flags a broken demo path that a real customer will never touch, because a prospect will touch it on Thursday. The defect is objectively minor and the business case for fixing it fast is real. Both people are right, and they're answering different questions.

The trap is treating severity and priority as one number that gets negotiated into a compromise. A defect that's medium severity, medium priority as a blended average is usually a defect where nobody actually agreed on anything, they just met in the middle to end the conversation. That's worse than disagreeing openly, because it hides which axis moved.

Who decides each one

This is the part most teams never write down, so it gets decided by whoever's in the room and loudest.

• Severity is a tester's or engineer's call. It's a technical assessment of what the code does, and it should be set by whoever actually understands the system's behavior, not by whoever is under the most pressure that week.
• Priority is the business's call. It belongs to whoever owns the release, the roadmap, or the customer relationship, typically a product manager or engineering lead, weighing the fix against everything else in the queue.

The failure mode is one person setting both. When a single project manager assigns severity and priority together, severity quietly becomes a proxy for urgency, and the record stops describing what's actually broken. Six months later, when someone tries to understand why a critical defect from last spring turned out to be a two pixel alignment issue, the history makes no sense, because severity was never really severity. It was priority wearing severity's label.

Making the disagreement visible on the record

The fix is procedural, not philosophical: keep severity and priority as two separate fields on every defect, set by two different roles, and let them disagree openly.

• Log severity first, based only on technical impact, before anyone discusses the release calendar.
• Log priority separately, and let it change over the defect's life without touching severity.
• If the two produce a surprising combination, like the Safari checkout example, write one line explaining why, so the next person reading the ticket six months later isn't confused.
• Never collapse the two into a single priority field just to save a column in the tracker. That's the averaging trap.

A defect record that shows severity low, priority high, reason campaign launch Thursday tells a future reader everything they need in one glance. A record that just says priority medium tells them nothing.

The related question of what actually counts as a defect worth logging in the first place matters here too. A team that's fuzzy on bug vs defect terminology tends to be just as fuzzy about severity and priority, because both confusions come from treating a documented defect record as optional busywork instead of the thing that makes disagreements resolvable later. Clear terminology and a two field defect record solve the same underlying problem: making the disagreement legible instead of silent.

Where this connects to defect management more broadly

Severity and priority are two fields inside a bigger defect record, and how that record gets triaged, reassigned, and closed is its own set of decisions. A clean severity and priority split only pays off if the rest of defect management is disciplined too, otherwise the two fields just add noise to a process that was already inconsistent.