01 Overview
Most arguments about a defect are not really arguments about the defect. They are arguments about the description of the defect. One person saw something go wrong, wrote it down in a hurry, and now a room full of people is debating whether it matters, who owns it, and whether it is even real. The shortest reproducing case ends that debate faster than any amount of seniority, eloquence, or escalation.
A reproducing case is a sequence of actions that takes a reader from a known starting point to the observed failure, every time, without the author standing next to them. When it is short, it is also diagnostic. A long case hides the cause inside dozens of irrelevant steps; a short one narrows the field until the responsible condition is nearly visible. That is why the shortest case wins: it is not just easier to follow, it is more informative.
This article is about the craft of building that case and using it. It covers what a report is actually claiming, how severity and priority differ, how to write steps another person can follow, how triage queues move, and what to do when a defect comes back after being closed. The thread running through all of it is simple: reduce until the failure is undeniable, then let the reduced case do the arguing.
02 What the report is actually claiming
Every defect report makes at least three claims, whether or not the author notices. The first is that something happened. The second is that it should not have happened. The third is that it will happen again under some describable conditions. A report that only establishes the first claim is an anecdote, not a defect. The second claim requires a stated expectation, and the third requires a reproduction.
Separating these claims changes how you write. "The save button is broken" asserts all three at once and supports none of them. "On build 412, with a fresh account, entering a title and pressing Save shows a spinner that never resolves; the record appears after reload" asserts an observation, an expectation, and a condition. A reader can now disagree with any one of them specifically, which is exactly what you want. Disagreement should be precise, not global.
It also helps to state what you did not test. If you only tried one browser, one account type, or one data shape, say so. That sentence prevents a triager from assuming the failure is universal and prevents an engineer from dismissing it as environment-specific. A report that is honest about its boundaries is more credible, not less, because it tells the reader exactly how much weight the evidence can bear.
03 Severity versus priority
Severity describes how much damage the defect does when it occurs. A crash that loses a user's work is severe. A misaligned label is not. Severity is a property of the failure itself, and it does not change because the team is busy. Priority describes when the team intends to act. A cosmetic defect on the checkout page can be high priority because it is the first thing every customer sees, while a severe crash in an obscure admin path can sit at low priority for months.
Confusing the two produces two familiar failure modes. Teams that treat severity as priority fix everything that sounds scary and ship nothing that matters. Teams that treat priority as severity quietly accept data loss because the path is rare, and then act surprised when it is not. Keeping the two columns separate lets a triager say, without contradiction, that a defect is severe and will be fixed later, or minor and will be fixed now.
For the person writing the report, the practical consequence is this: argue severity with evidence, and let priority be a product decision. Describe the damage concretely, including what a user loses and whether recovery is possible. Do not inflate severity to win a scheduling fight. Inflated severity is the fastest way to lose credibility on the reports that genuinely deserve attention, and credibility is the only currency a tester has in triage.
04 Writing steps someone else can follow
Good steps begin from a state another person can actually reach. "Log in as a user with two saved addresses" is a starting point. "Use my account" is not. Name the build, the environment, and any data the case depends on, then list actions in the order you performed them, one action per line, using the same words the interface uses. If the interface says Publish, do not write "submit." Small vocabulary mismatches send readers down wrong paths.
After the actions, state the observed result and the expected result as two separate sentences. This is the part authors skip, and it is the part that makes the report actionable. "Observed: the confirmation banner does not appear and the item remains in Draft. Expected: the banner appears and the item moves to Published." Now a reader can tell instantly whether they reproduced the same thing or something adjacent. Adjacent failures are common and worth reporting, but they should not be smuggled into the original case.
Finally, reduce. Once you have a case that works, try removing steps, changing data, and simplifying the environment until the failure stops or the case cannot shrink further. Keep the last version that still fails. That version is your report. Reduction takes time, but it saves more time than it costs, because every reader after you spends less effort understanding and more effort fixing.
05 Running the triage queue
Triage is a routing decision, not a verdict on quality. Each report leaves the queue with one of a small set of outcomes: accepted and assigned, deferred with a reason, marked duplicate of an existing report, sent back for more information, marked cannot-reproduce with the attempts recorded, or closed as not-a-bug with the expectation explained. Every outcome needs an owner and a next action, or the queue simply relocates the ambiguity.
A useful discipline is to timebox reproduction attempts and write down what was tried. "Attempted on build 412 in two browsers with a fresh account; could not reproduce" is a legitimate outcome and a useful artifact. It tells the reporter what to add, and it tells the next triager that the ground has already been covered. What damages a queue is the silent bounce, where a report moves between people without any recorded attempt, so that everyone believes someone else checked.
Duplicates deserve care rather than annoyance. When you merge, link the reports and note which one carries the better reproduction, because the better case should become the canonical one regardless of which arrived first. Deferrals should carry a trigger: a condition under which the team will revisit. A deferral without a trigger is a quiet rejection wearing a polite label, and it will resurface at the worst possible moment.
06 When a defect comes back
A reopened defect is information, not an insult. It usually means one of four things: the fix addressed a symptom rather than the cause, the original case was narrower than the real failure, the fix introduced a new path to the same symptom, or the verification was done against the wrong build. The first job on reopen is to determine which, because each demands a different response.
Start by re-running the original case exactly as written. If it passes, widen deliberately: vary the data, the account state, the sequence, and the environment, one dimension at a time, until the failure returns. The moment it returns, you have a new and usually more valuable case, because it captures a condition the first report missed. Update the report with that condition rather than filing a fresh one; the history matters to whoever fixes it next.
If the original case fails again on the build that was supposed to contain the fix, say so plainly and attach the build identifier. Avoid speculating about cause in the report itself. Your leverage is the reproduction, not the diagnosis. A short case that fails on the fixed build is the strongest possible statement, and it needs no adjectives to be persuasive. Keep the tone procedural, keep the evidence tight, and let the case do the arguing.
07 Frequently asked questions
How short is short enough? Short enough that a reader can follow it without asking you a question, and no shorter. If removing a step makes the case unreliable or ambiguous, you have found the floor. The goal is not minimalism for its own sake; it is a case that fails every time and can be understood in one reading.
What if I cannot reproduce it reliably? Say so, and describe the conditions under which you saw it, including frequency and any pattern you noticed. An intermittent report with honest frequency data is useful. An intermittent report dressed up as a certainty is not, because it sets false expectations and wastes reproduction effort. Record what you tried, and mark the report as needing more evidence.
Should I include a guess at the cause? Keep it clearly separated from the facts, or leave it out. A guess can help, but when it is blended into the steps it contaminates the evidence and anchors the reader. Write the case first, then, if you must, add a short note labeled as speculation.
What if triage disagrees with my severity? Ask what evidence would change the assessment, then go get it. Severity arguments are won with demonstrations, not repetition. If the disagreement is really about priority, that is a scheduling decision, and the right move is to make the impact visible rather than to relabel the defect.