01 Overview
Every release is a negotiation between what is broken and what is tolerable. Blocking bugs sit at the sharp end of that negotiation: they are the defects severe enough that shipping around them would mean shipping something the team cannot stand behind. The trouble is that the word blocking gets used loosely. A defect that blocks one person's workflow on an unusual configuration is not the same as a defect that blocks every new user from completing signup. When teams treat those as equivalent, the queue fills with noise, real blockers wait behind false ones, and severity stops meaning anything.
Severity inflation is the slow drift where defects get labeled more damaging than they are, usually to win attention in a crowded backlog. It is rarely malicious. A tester who has watched a fix sit untouched for weeks learns that a higher severity gets a faster response. A product owner who fears a bad launch learns to escalate. Each individual bump feels defensible, but the aggregate effect is a queue where everything is urgent and nothing is. The craft answer is not to stop caring about defects. It is to make severity a claim about damage that can be examined, contested, and corrected.
This article treats the blocking bug as a specific, defensible category rather than a rhetorical one. It covers what a report is actually asserting, how severity differs from priority, how to write steps that survive handoff, how to run a triage queue without inflating labels, and what to do when a defect returns after being marked fixed.
02 What the report is actually claiming
A defect report is a set of claims, and the most important one is usually implicit. The reporter is claiming that a specific behavior occurs under specific conditions, that this behavior is wrong relative to some expectation, and that the wrongness matters. Each of those can be true or false independently. The behavior may occur but only under conditions the reporter did not realize were unusual. The behavior may be intended, with the expectation being outdated. The behavior may be genuinely wrong but matter far less than the reporter assumes.
When a report says a defect is blocking, it is making a stronger claim: that work cannot proceed until this is resolved. That claim deserves scrutiny because it is a claim about the whole team's options, not just the reporter's experience. A blocking claim should answer a simple question: who or what is stopped, and what would they do instead if the defect shipped? If the honest answer is that most users would never encounter it, or that a workaround exists that is annoying but usable, then the defect may be severe without being blocking.
Good reporters separate observation from interpretation. The observation is the behavior, the build, the environment, and the steps. The interpretation is the severity and the proposed priority. Keeping those distinct lets triage accept the observation while adjusting the interpretation, which is far less personal than arguing about whether the reporter was right to file it. A report that states its evidence plainly and its judgment modestly is easier to route correctly and harder to dismiss.
03 Severity versus priority
Severity describes damage. It answers what happens if this defect reaches users: does it corrupt data, block a core journey, degrade performance, or merely annoy. Severity is a property of the defect and the product, and it should be stable across teams and time. A defect that prevents account creation is high severity whether it is found on Monday or Friday, whether the team has capacity or not. Severity is the part of the report that should be argued with evidence about impact.
Priority describes scheduling. It answers when the team intends to work on this relative to everything else. Priority is a property of the team's situation, and it legitimately changes as deadlines, dependencies, and risk tolerance change. A high-severity defect in a feature that is not shipping this quarter can carry lower priority than a moderate-severity defect in the exact flow the release depends on. That is not hypocrisy; it is the difference between damage and timing.
Conflating the two is what makes severity inflation so tempting. If severity is treated as a proxy for when something gets fixed, then the only way to get attention is to inflate severity. The fix is procedural: let severity be assigned on impact, let priority be assigned on scheduling, and let them disagree openly. A defect can be high severity and low priority, and the report should say so without embarrassment. Triage then has two honest levers instead of one contested one, and the queue reflects real tradeoffs rather than whoever argued hardest.
04 Writing steps someone else can follow
The repro steps are the part of the report most likely to be skimmed and most likely to waste time. The goal is the shortest sequence that reliably triggers the defect on a known build and environment. Shortest matters because every extra step is a place for the reproducer to diverge. Reliable matters because a defect that triggers one time in five needs that stated explicitly, not hidden behind steps that imply certainty. A reader should be able to follow the steps without asking a single clarifying question.
Start from a defined state. Say which build, which environment, which account, and which preconditions matter. If the defect only appears with a populated cart or an expired session, that is a step, not an aside. Then list actions in order, one action per line, using the same vocabulary the interface uses. Avoid describing intent; describe the action. Clicking a button labeled Save is clearer than trying to save the record. When the defect appears, state what was observed and what was expected, in that order, so the gap is unambiguous.
Finally, note what does not trigger it. If the defect vanishes in a different browser, on a fresh account, or after a restart, that negative information narrows the search space and often points straight at the cause. Attach evidence that supports the claim rather than everything available: a short recording, a log excerpt, a screenshot of the exact state. The test of good steps is simple. Hand them to someone who has never seen the defect and watch whether they reproduce it without help. If they need help, the steps are not finished.
05 Running the triage queue
Triage is a routing decision, not a debate about whether the reporter was right. The queue exists to move each report to a defensible next action: assign a severity, assign a priority, name an owner, and set a status. A well-run triage is fast because it relies on stated criteria rather than fresh argument each time. The criteria should be written down and visible, so that a new report can be compared against them instead of against the loudest voice in the room.
A practical triage asks a short sequence of questions. Does the report contain enough evidence to act on, or does it need more information before it can be judged? If it needs more information, the correct routing is back to the reporter with a specific ask, not a speculative severity. If it is actionable, what is the damage if it ships, and who is affected? That sets severity. Then, given the current release plan and capacity, when should this be worked? That sets priority. Finally, who owns the next action, and what is the status that reflects it?
Two disciplines keep triage honest. First, record the reasoning, not just the label, so that later readers understand why a defect was rated as it was. Second, review the distribution periodically. If nearly everything is high severity, the scale has stopped carrying information, and the team should recalibrate against examples rather than defend individual calls. Triage is also where blocking claims get tested. A defect is blocking only if the team agrees that shipping with it is unacceptable, and that agreement should be explicit rather than assumed from the label.
06 When a defect comes back
A defect that returns after being marked fixed is not a failure of the process; it is information the process was missing. The first question is whether it is the same defect. Sometimes the original cause was fixed and a different cause produces a similar symptom, which means the new report should be linked to the old one but triaged on its own evidence. Treating it as a reopening without checking can send the team chasing a fix that already landed.
If it is genuinely the same defect, the useful move is to ask why verification did not catch it. Common answers are that the fix addressed a symptom rather than the cause, that the verification used different data or environment than the original repro, or that the fix introduced a regression elsewhere. Each of those points to a specific improvement: strengthen the repro, align the verification environment, or add coverage around the changed area. The point is not to assign blame but to close the gap that let the defect through.
Reopened defects also carry a severity question. A defect that returns is often more damaging than one that never left, because it erodes trust in the fix and may have reached users in the interim. That can justify raising severity on impact grounds, not as punishment. What it should not justify is an automatic jump to blocking. The same test applies as before: who is stopped, and can they proceed another way? Answer that honestly, record the reasoning, and let the queue reflect the real cost of the recurrence.
07 Frequently asked questions
Is a blocking bug always the highest severity? Not necessarily. Blocking is a claim about whether the team can ship, which is a scheduling judgment, while severity is a claim about damage. A defect can be severe without blocking a particular release, and a defect can block a release without being catastrophic if it hits the exact flow the release depends on. Keeping the two separate prevents the label from doing work it cannot do.
How do I push back on an inflated severity without starting a fight? Argue about impact, not about the reporter. Ask who is affected, how often, and what the workaround is. If the answers support a lower severity, say so plainly and record the reasoning. If they support the original rating, accept it. The goal is a shared scale, not a victory.
What if I cannot reproduce a reported defect? Say so in the report and describe what you tried. A defect that cannot be reproduced is not automatically invalid; it may depend on state, timing, or data you do not have. Route it for more information rather than closing it, and note the conditions under which it was seen.
Should every defect get a severity and a priority? Yes, even small ones, because the act of assigning forces the impact and timing questions to be answered. A defect with no severity is a defect nobody has decided anything about, and it will sit in the queue until someone does.