01 Overview
Every defect report carries two separate judgments, and confusing them is one of the most common sources of friction between testers and engineers. The first judgment is severity: how much damage the defect causes when it actually occurs. The second is priority: when the team intends to fix it. These are not the same question, and they do not always point the same direction. A crash that wipes a rarely used preference file may be severe in kind but low in priority because almost nobody touches it. A cosmetic misalignment on the checkout button may be trivial in kind but high in priority because it sits in front of every buyer during a launch week.
This article treats severity and priority as craft concepts, not as fields to fill in mechanically. The goal is to help testers describe damage accurately and help teams schedule work honestly. Severity belongs to the defect; priority belongs to the plan. A tester who understands the difference writes reports that survive review without argument. A team that understands the difference stops relitigating the same ticket every sprint.
The practical payoff is a triage queue that moves. When severity is argued with evidence and priority is decided with context, the routing decision becomes fast and defensible. When the two are tangled together, every ticket becomes a debate about everything at once, and the queue stalls.
02 What the report is actually claiming
A defect report is a claim about observed behavior, not a story about the day it was found. The strongest reports separate what was expected from what happened, and then supply the shortest path that reproduces the gap. Everything else, screenshots, logs, environment notes, is supporting evidence for that core claim. If a reader cannot state the claim in one sentence after reading the title and summary, the report is not finished.
The claim has three parts. First, the affected area: the component or surface where the failure shows up, named precisely enough that the right engineer recognizes it as theirs. Second, the observable failure: what the system did instead of what it should have done, described without interpretation. Third, the conditions: the data, configuration, role, or timing that made the failure appear. A report that says a page is broken is not a claim; a report that says the invoice total rounds down when a discount and a tax line are both present is a claim.
Testers often weaken their own reports by editorializing. Words like obviously, terrible, or should never happen add heat without adding information. Engineers reading a queue at the end of a long day respond to precision, not volume. Write the claim so a skeptical reader could try to falsify it. If they can, you have given them something to work with, and the conversation moves from whether the defect is real to what to do about it.
03 Severity versus priority
Severity describes damage. Ask what happens when the defect fires: does it corrupt or lose data, block a core task, degrade performance, mislead the user, or merely look wrong? Consider scope, depth, and recoverability. A failure that silently writes incorrect values into a record is more severe than one that shows an error and refuses to proceed, because the silent version leaves damage behind. A failure with a clean workaround is less severe than one with none. Severity should be defensible from the reproduction alone, without knowing anything about the roadmap.
Priority describes scheduling. Ask when this should be fixed relative to everything else: before the next release, in the next maintenance window, when the owning team next touches that area, or never. Priority legitimately depends on context outside the defect, including release timing, contractual commitments, how many users hit the path, the cost of the fix, and the risk of the fix itself. A low-severity defect on a critical path can outrank a high-severity defect in a deprecated feature that is scheduled for removal.
The failure mode to watch for is letting one field silently stand in for the other. Teams that only track severity end up fixing interesting defects instead of important ones. Teams that only track priority lose the record of how bad things actually are, which makes risk invisible until it is expensive. Keep both, and when they diverge, say so explicitly in the triage notes. A defect that is severe but low priority is a known, accepted risk. A defect that is minor but high priority is a deliberate choice about timing. Both are fine decisions when they are written down.
04 Writing steps someone else can follow
Reproduction steps are instructions, not a diary. Start from a known state, list the actions in order, and stop at the first point where the failure is visible. If a step can be skipped without changing the outcome, cut it. The test of a good step list is simple: hand it to a colleague who has never seen the feature, and watch whether they reach the same failure without asking you a question.
Begin with preconditions: the account type, the data setup, the configuration, the build, and anything else that must be true before step one. Then number the actions, one action per step, using the interface's own labels. Name the exact input values rather than describing them. Where the failure is timing-dependent, say what the timing was, and note whether you reproduced it more than once. If the defect is intermittent, say so plainly and describe the conditions that seemed to raise the odds, without claiming a rate you did not measure.
End with the observed result and the expected result, stated separately. Attach the smallest evidence that proves the point: a log excerpt, a screenshot, a response body. Avoid pasting an entire console dump when three lines carry the signal. Finally, keep the steps current. When a fix lands and the steps no longer reproduce, update them or mark the report accordingly. A stale reproduction is worse than none, because it sends the next reader down a path that no longer exists.
05 Running the triage queue
Triage is a routing decision, not a verdict on anyone's work. The queue exists to answer one question per report: what happens next, and who owns it? A healthy triage session confirms the defect, checks for duplicates, assigns severity and priority, picks an owner, and records the reason for the decision. Every report leaves with a status and a next action. Reports that leave with neither are the ones that rot.
Run the queue on a fixed cadence with a small, empowered group: someone who knows the product, someone who knows the code, and someone who can speak to release commitments. Sort by risk rather than by arrival order, because the oldest ticket is not automatically the most dangerous. When a report is unclear, the fastest path is usually to ask the reporter one specific question rather than to guess. When a report is a duplicate, link it and close it, but keep the better reproduction.
Record the reasoning, especially for the uncomfortable calls. When a severe defect is deferred, write down why and who accepted the risk. When a minor defect is escalated, write down what makes it urgent. These notes are what let a team revisit decisions honestly instead of arguing from memory. They also protect the tester, who should never have to defend a severity rating alone in a hallway conversation. The queue is a shared instrument, and its value comes from the consistency of the decisions it produces.
06 When a defect comes back
Reopened defects carry information, and the first job is to read it correctly. A report that returns after a fix usually means one of a few things: the fix addressed a symptom rather than the cause, the reproduction depended on conditions the fix did not cover, the original steps were incomplete, or the failure is genuinely intermittent and the fix reduced but did not eliminate it. Each of these calls for a different response, so resist the urge to simply reassign the ticket and move on.
Start by re-running the original steps exactly as written. If they no longer reproduce, try the variations the fix might have missed: different data, different roles, different timing, a different entry point into the same code path. Compare the new failure to the old one carefully. A defect that looks similar but fails at a different point may be a new issue wearing the old ticket's number. If it is new, open a fresh report and link the two rather than burying the new evidence in a closed thread.
When you confirm a genuine reopen, update the report rather than starting over. Add the new conditions, revise the steps, and note what the previous fix changed. Then send it back through triage with that context attached, so the next decision is made with the full history. A reopened defect is not a failure of the process; it is the process working. The alternative, shipping a fix that nobody re-verified, is how small problems become incidents.
07 Frequently asked questions
Can a defect be high severity and low priority? Yes, and it happens often. Severity measures damage when the defect fires; priority measures when the team intends to fix it. A severe failure in a deprecated feature that few users reach may legitimately sit low in the queue. The important thing is to record the divergence and the reason, so the accepted risk is visible rather than accidental.
Who decides priority? Priority is a scheduling decision, so it belongs to whoever owns the plan, typically a product or engineering lead working with the team. Testers supply severity with evidence and should not be asked to defend a schedule they do not control. When the two roles disagree, the disagreement is usually about context, not about the facts of the defect.
What if I cannot reproduce a defect reliably? Report it anyway, but be honest about the uncertainty. Describe what you saw, how many times you saw it, and the conditions that seemed relevant. Mark it as intermittent and include whatever evidence you captured at the time. An intermittent report with good evidence is far more useful than a confident report with none.
How much detail is too much? Enough detail that a stranger can reproduce the failure and understand its impact, and no more. Trim anything that does not change the outcome, and keep the reproduction minimal. Precision earns attention; volume dilutes it.