01 Overview
Severity ranking is usually taught as a judgment about how bad a bug is. That framing invites arguments, because bad is a feeling and feelings differ by role. A tester who watched a checkout fail feels the bug is catastrophic; an engineer who knows the failure needs an unusual sequence feels it is minor; a product owner who sees the calendar feels it is urgent. None of them is wrong about their own vantage point, and that is exactly why the conversation stalls.
A more useful frame is blast radius. Blast radius asks a narrower, answerable question: if this defect fires, how far does the damage travel? Does it corrupt one record or every record in a batch? Does it break one screen for one role, or does it block a shared dependency that other features rely on? Does it produce a wrong result silently, or does it fail loudly where someone will notice immediately? Those questions have evidence behind them, and evidence can be checked.
This article treats severity as a blast radius question and priority as a scheduling question, then walks through the reporting and triage habits that keep the two from collapsing into each other. The goal is not a perfect scale. The goal is a shared, defensible way to decide what ships and what waits.
02 What the report is actually claiming
Every defect report makes a claim, whether or not the author states it plainly. The claim is usually some version of: under these conditions, this system does this wrong thing, and that matters because of who or what it touches. When a report is hard to triage, it is often because one of those pieces is missing or implied rather than written down. The reader is left to guess at the conditions, the wrongness, or the stakes.
Separating the claim into parts helps. There is the trigger, which is the state and sequence that produces the behavior. There is the observation, which is what the system actually did, described without interpretation. There is the expectation, which is what should have happened and why anyone believes that. And there is the impact, which is the reach of the wrongness once it occurs. A report that supplies all four is triageable in minutes; a report missing impact may be technically perfect and still sit unranked for days.
It also helps to notice when a report is really two claims wearing one coat. A crash on a settings screen and a crash that also wipes saved preferences are related but not identical, and their blast radii differ. Splitting them lets each be ranked on its own evidence instead of inheriting the scariest part of the pair. The discipline of restating the claim in your own words before ranking it catches most of these tangles early.
03 Severity versus priority
Severity and priority answer different questions, and the most common triage failure is letting one silently stand in for the other. Severity is about damage: how wide the blast radius is when the defect occurs. Priority is about scheduling: when the team intends to act, given everything else competing for the same hands and hours. A defect can be high severity and low priority, or low severity and high priority, and both combinations are legitimate.
High severity with low priority looks strange until you examine exposure. A defect that destroys data but only triggers in a deprecated path that almost nothing calls has a large theoretical blast radius and a small practical one. The damage would be severe if it happened; the odds and the reach are low, so it can wait behind work that affects daily users. Low severity with high priority is the mirror image: a cosmetic glitch on the first screen every new user sees does little damage per occurrence but sits directly in the path of a launch, so it gets scheduled first.
Keeping the two separate in the record matters because they change for different reasons. Severity changes when new evidence widens or narrows the blast radius, such as discovering the corruption also propagates to a reporting table. Priority changes when the calendar, the customer commitment, or the surrounding work changes. If the two are stored as one field, every scheduling shift looks like a re-ranking of damage, and the history becomes unreadable.
04 Writing steps someone else can follow
Reproduction steps are the part of a report most likely to be skimmed and most likely to be wrong. The test is simple: can a person who has never seen this feature follow the steps from a known starting state and observe the same result? If the steps begin mid-journey, assume a particular account, or skip the environment, the answer is no, and the report will bounce back for information before anyone can rank it.
Start from a state you can name. Say which build, which environment, which role or account type, and which data the steps assume. Then give the shortest ordered sequence that reliably triggers the behavior, one action per step, using the words that appear in the interface rather than your own shorthand. End with the observed result and the expected result stated separately, because mixing them into one sentence hides which part is the surprise. If the defect is intermittent, say so and describe how often you saw it and what you tried, rather than presenting a lucky run as a guarantee.
Trim before you submit. Extra steps that do not affect the outcome make the report harder to verify and easier to dismiss when someone follows them and sees nothing. If you can remove a step and still reproduce, remove it. A short, reliable sequence is worth more at triage than a long narrative, and it gives the fixer a fast loop for confirming the repair later.
05 Running the triage queue
Triage is a routing meeting, not a debate about whether the bug is interesting. The queue arrives with reports in various states of completeness, and the job is to move each one to a decision: accept it with a severity and priority, defer it with a reason, mark it duplicate of an existing report, send it back for information, or close it as not a defect. Every outcome is a valid outcome as long as the reason is recorded where the reporter can see it.
Run the queue against a stable definition of each severity level so the same evidence produces the same rank across sessions and across people. When a report is incomplete, the fastest path is usually to send it back with a specific question rather than to guess at the missing impact. Guessing inflates some reports and buries others, and it teaches reporters that detail does not matter. Naming an owner at the moment of acceptance prevents the quiet failure where a report is ranked correctly and then belongs to no one.
Keep the queue short and the cadence predictable. A backlog of untriaged reports is not a measure of quality; it is a delay in the feedback loop that reporters depend on. If the queue grows, the fix is usually to tighten the intake template, not to triage faster, because most slow decisions trace back to reports that never stated their blast radius.
06 When a defect comes back
A defect that returns after being marked fixed is not a new report; it is evidence about the previous one. The first move is to compare the new reproduction against the old steps. If the same steps now fail again, the fix did not hold, and the question becomes what changed: a later change reverted it, the fix covered one path and not its siblings, or the original diagnosis was wrong about the cause. If the steps differ, you may be looking at a related but distinct defect that deserves its own record and its own blast radius.
Reopening should carry the history forward rather than starting clean. The original severity and priority are a useful baseline, but they are not automatically correct on return. A defect that came back may now sit in a wider path, or the surrounding work may have moved on, so re-rank it on current evidence and say in the record why the rank changed. Silent re-ranking is how teams end up arguing about a number instead of the behavior.
Treat each return as a signal about the verification that let it through. Ask whether the original fix was checked against the full set of conditions in the report, and whether adjacent paths were exercised. The answer usually improves the next verification pass more than any change to the severity scale.
07 Frequently asked questions
How do I rank a defect when I cannot tell how many users it affects? Rank the reach you can demonstrate and note the uncertainty explicitly. A defect confirmed on one path with unknown spread is not the same as one confirmed across every path, and the record should say which you have. If the answer changes the rank, that is a reason to gather one more piece of evidence, not a reason to pick a number and move on.
What if severity and priority disagree and nobody will budge? Separate the two fields in the record and make each side state its reasoning in its own terms. The damage argument and the scheduling argument can both be true. Writing them down side by side usually reveals that the disagreement is about exposure or timing, which is a question someone can actually answer.
Should a tester assign priority? A tester can propose it, but priority belongs to whoever owns the schedule, because it depends on commitments the tester may not see. The tester's strongest contribution is a well-evidenced severity and a reproduction anyone can follow.
How much detail is too much? Enough to reproduce and enough to judge reach, and no more. Extra narrative slows triage without changing the decision.