01 Overview
Every team starts with a severity scale that feels obvious. Critical means the product is down, major means a core flow is broken, minor means something looks wrong but still works, and trivial means nobody would notice unless they were told. For a few months this shared understanding holds. Then people change teams, new hires join, a release slips, and the same words start meaning different things to different people. Nobody decides to let the scale drift. It drifts because the words were never anchored to anything concrete.
The drift is not a discipline problem. It is a documentation problem. A severity scale without a rubric is a set of adjectives, and adjectives are interpreted through the lens of whoever is reading them at that moment. A tester who just watched a payment fail will call it critical. An engineer who knows the retry logic usually recovers will call the same failure major. Both are describing what they saw, and both are being sincere. The disagreement is about meaning, not honesty.
A rubric fixes this by tying each level to observable conditions rather than feelings. It says what must be true for a defect to earn a given severity, what evidence must accompany the report, and who has the authority to change the call. The rubric does not remove judgment. It gives judgment something to push against, so the conversation moves from arguing about words to comparing the report against a shared standard.
02 What the report is actually claiming
Before a defect can be graded, it has to be understood. A report is a claim about the world: that under certain conditions, the product does something it should not do. The claim has parts, and each part can be wrong. There is the environment, the input, the action taken, the observed result, and the expected result. If any of those are missing or vague, the severity conversation is premature because nobody can agree on what happened.
Testers often compress this into a single sentence, which is efficient for the writer and expensive for everyone else. A title like checkout broken forces the reader to reconstruct the claim from scratch. A better report states the surface, the precondition, the action, and the divergence between observed and expected behavior. That structure is not bureaucratic ceremony. It is the minimum information needed to decide whether the defect is severe, whether it is even a defect, and who should look at it.
The most common failure is a report that describes a symptom without a mechanism. The screen went blank is a symptom. Whether that blank screen lost a submitted order or merely hid a loading spinner changes the severity entirely. When the claim is unclear, the honest triage response is not to guess a severity but to send the report back for the missing piece. That feels slow in the moment and saves days of misrouted work later.
03 Severity versus priority
Severity and priority answer two different questions, and conflating them is the single largest source of scale drift. Severity asks how much damage the defect does. Priority asks when the team intends to fix it. A defect can be high severity and low priority, or low severity and high priority, and both combinations are legitimate. A crash that only occurs on an obsolete device configuration may be severe when it happens and still wait behind a release blocker.
The reason teams collapse the two is that severity feels like it should determine scheduling. It does not, because scheduling depends on factors severity cannot see: how many users hit the path, whether a workaround exists, what else is competing for the same engineers, and what the release commitments are. A cosmetic defect on the signup screen can outrank a data-corruption bug in an internal tool simply because of exposure. That is not a moral failing. It is triage doing its job.
Keeping the two separate also protects the severity scale from political pressure. When severity is treated as a proxy for priority, people inflate severity to get attention, and the scale loses its meaning within a quarter. When severity is a factual assessment of damage and priority is a scheduling decision, a team can honestly say a defect is severe and still defer it, with the reasoning written down. The rubric should define severity levels by impact and leave priority to the review meeting.
04 Writing steps someone else can follow
Reproduction steps are the backbone of a defect report, and they are where most reports quietly fail. The test is simple: can a person who has never seen this feature follow your steps and observe the same result? If the answer requires tribal knowledge, the steps are incomplete. Start from a known state, name the exact inputs, and describe each action in the order it must occur. Do not summarize. Do not skip the step you think is obvious.
Good steps are minimal and deterministic. Minimal means every step is necessary; if removing a step still reproduces the defect, that step is noise and it slows down whoever investigates. Deterministic means the result does not depend on timing, cached state, or luck. If the defect only appears intermittently, say so explicitly and describe what you tried to narrow it down. An intermittent defect with honest notes is far more useful than a confident report that cannot be reproduced.
Include the environment details that could plausibly matter: the build or version, the account or role used, the data state, and any configuration that differs from default. Then state the observed result and the expected result in separate sentences. This last habit is small and disproportionately valuable, because it forces the writer to articulate why the behavior is wrong. A defect report that cannot state the expected result is often not a defect at all, but a misunderstanding of intended behavior.
05 Running the triage queue
Triage is a routing decision, not a debate about worth. The meeting should move each new report toward one of a small number of outcomes: confirmed and assigned, sent back for more information, marked as intended behavior, or closed as a duplicate. Every outcome needs an owner and a next action. A triage session that ends with a pile of reports marked maybe has not triaged anything; it has merely postponed the decision under a different name.
The most valuable discipline in triage is separating the assessment from the argument. First, establish what the defect is and whether it reproduces. Then assign severity against the rubric. Then, and only then, discuss priority and scheduling. When teams reverse this order, the severity conversation becomes a negotiation about resources, and the rubric is abandoned in favor of whoever argues hardest. Keeping the sequence fixed makes the meeting shorter and the outcomes more consistent.
Triage also needs a record of why a decision was made, not just what the decision was. A short note explaining that a defect was rated major because it blocks a core flow for a subset of accounts, and deferred because a workaround exists, is worth more than any label. Months later, when someone asks why an obvious problem sat untouched, that note is the answer. The ledger of reasoning is what keeps the scale honest across team changes and release cycles.
06 When a defect comes back
A defect that returns after being marked fixed is not a failure of the original report. It is new information, and it deserves a fresh look rather than a reopened argument. The first question is whether it is genuinely the same defect or a different one that shares symptoms. Similar-looking failures often have unrelated causes, and treating them as one report muddies both the history and the fix. Compare the reproduction steps, the affected area, and the mechanism before deciding.
If it is the same defect, the next question is why the fix did not hold. Common answers include a fix that addressed a symptom rather than the cause, a fix that was correct but incomplete across related code paths, or a regression introduced by later work. Each of these points to a different follow-up. The value of asking is that it turns a frustrating recurrence into a specific, actionable finding instead of a general complaint about quality.
Recurring defects should also prompt a review of the verification step. If the original fix was verified only against the exact reported steps, it may never have been tested against nearby variations. Strengthening verification for that area, and noting the gap in the report, prevents the same cycle from repeating. The goal is not to assign blame but to close the loop between reporting, fixing, and confirming, so the ledger reflects reality rather than intention.
07 Frequently asked questions
How often should a severity rubric be reviewed? A practical rhythm is to revisit it when the team changes shape, when a release exposes a disagreement, or on a fixed cadence such as twice a year. The review should examine real reports from the period and ask whether the assigned severities still look right. If several reports were graded inconsistently, the rubric is missing a condition, not the people applying it.
What if two people disagree on severity? Use the rubric as the tiebreaker and, if it does not resolve the disagreement, treat that as a signal the rubric needs a new example. Escalate to whoever owns the scale, record the decision, and add the case to the rubric's examples. Over time the examples do more work than the definitions, because people pattern-match against concrete cases far more reliably than against abstract language.
Should every defect have a severity? Yes, even trivial ones, because an ungraded report is an undecided one. But severity should be cheap to assign and easy to revise. The point of the scale is not precision for its own sake; it is to make the routing decision fast, consistent, and explainable. A scale that is defended too rigidly becomes a source of conflict, and a scale that is never defended becomes noise. The rubric is what keeps it useful.