01 Overview
A reproduction is not a description of a bug. It is a procedure that produces a bug on demand. The difference matters because a description can be argued with, while a procedure can be run. When you trim your repro steps until the bug disappears, you are doing the most valuable kind of reduction work in testing: finding the smallest set of actions that still triggers the failure, and proving that removing any one of them stops it. That minimal sequence is what turns a vague complaint into a fixable defect.
Trimming is not about making the report shorter for its own sake. It is about isolating cause. Every extra step is a place where the reader can diverge from your path, and every unnecessary condition is a hypothesis you have not tested. A long repro hides the trigger inside a crowd of irrelevant actions. A short repro points at the trigger directly. The goal is a sequence a stranger can follow on a clean build and see the same result, with no prior context and no lucky timing.
The craft here is disciplined subtraction. You start with everything you did, then remove one thing at a time and re-run. If the bug survives, that step was noise. If the bug vanishes, you have found a necessary condition, and you put it back. What remains is the shortest reliable path, and that path is the real content of the report.
02 What the report is actually claiming
Before you trim anything, read the report as a claim about the world. Most reports contain several claims tangled together: that something happened, that it happened under certain conditions, that it is wrong, and that it matters. Your job is to separate the observable claim from the interpretation. The observable claim is the part a camera could record. The interpretation is the part where the reporter tells you why it happened or how bad it is.
A useful report states a single expected result and a single actual result. If the reporter says the save button is broken, ask what they expected after pressing it and what they saw instead. If they say the list is wrong, ask which list, sorted how, containing what. Ambiguity in the claim becomes ambiguity in the fix. Two engineers can read the same sentence and build two different corrections, neither of which addresses the real problem.
Trimming also exposes claims that are not defects at all. Sometimes the behavior is correct and the expectation was wrong. Sometimes the environment was stale, the build was old, or a cached value was showing. When you reduce the steps and the bug disappears, you have not failed. You have learned that the original claim depended on something you removed, and that something is now the most interesting part of the investigation. A report that survives reduction is trustworthy. A report that does not survive tells you where to look next.
03 Severity versus priority
Severity describes damage. It answers what happens when the defect occurs: does it corrupt data, block a core task, mislead a user, or merely annoy. Priority describes scheduling. It answers when the team intends to act. These are related but not identical, and conflating them is one of the most common sources of triage friction. A crash in a rarely used admin screen can be high severity and low priority. A typo on the main landing page can be low severity and high priority because it is seen by everyone.
Severity should be judged from the product and the user, not from the effort to fix. A defect that silently writes the wrong value is severe even if the patch is one line. A defect that makes a screen ugly is not severe even if the fix is a week of work. When you assign severity, describe the consequence in plain terms: what task fails, what data is wrong, what decision a user might make incorrectly. That description survives re-prioritization and helps whoever picks up the ticket later.
Priority belongs to the team, not the reporter. It depends on release timing, how many users hit the path, whether a workaround exists, and what else is competing for the same hours. A good report supplies the facts that inform priority without demanding a rank. State the impact, note the workaround if one exists, and let triage decide. When severity and priority diverge, say so explicitly, because that gap is exactly what the triage meeting exists to resolve.
04 Writing steps someone else can follow
A repro is a recipe, and a recipe assumes nothing. Start from a known state: which build, which environment, which account, which data. Then give numbered actions in the order they must occur. Each action should be a single observable operation, not a summary of several. Press this, type that, wait for this to appear. If a step depends on a prior step having succeeded, say what success looks like so the reader knows whether to continue.
Name the exact values you used. The specific search term, the exact field contents, the precise sequence of clicks. Generic instructions like open the settings page and change the option force the reader to guess, and guessing produces different results. Where a value matters, give it. Where it does not, say so, because that tells the reader which variations are safe to try. Include the expected result and the actual result as separate lines at the end, so the divergence is unmistakable.
Then trim. Remove a step and re-run from a clean state. If the bug still appears, the step was not needed. If it disappears, restore the step and mark it as required. Repeat until every remaining step is load-bearing. The final sequence should be short enough to read in one pass and precise enough that a colleague on a different machine gets the same failure. That is the standard: reproducible by a stranger, not merely believable to a friend.
05 Running the triage queue
Triage is a routing decision, not a debate about whether the bug is real. The queue exists to move each report to the right owner with the right severity, priority, and next action. A well-run queue is fast and boring. Reports arrive, get read, get classified, and leave with an owner. The meeting is not the place to debug. If a report cannot be classified because the repro is unclear, the correct action is to send it back for reduction, not to spend the room's time guessing.
Good triage depends on good inputs. A report with a minimal repro, a clear expected versus actual, and a stated affected area can be routed in seconds. A report without those things consumes the whole session and still leaves with a vague assignment. This is why trimming belongs upstream of triage. The work you do before the meeting determines whether the meeting is a routing desk or a rescue operation. Protect the queue by refusing to triage reports that have not been reduced.
During triage, separate the questions. Is it a defect at all. If so, how much damage. When should it be fixed. Who owns the area. What is the next action. Answer them in that order and record the answers on the report. Status should reflect reality: new, triaged, in progress, fixed, verified. A report that sits in the wrong status misleads everyone downstream, including the people deciding what ships.
06 When a defect comes back
A reopened defect is information, not failure. It usually means one of three things: the fix addressed a symptom rather than the cause, the original repro was incomplete, or the environment changed in a way nobody accounted for. The first move is to compare the new failure against the old repro. If the trimmed steps no longer trigger it, the defect has changed shape, and you are now investigating a different problem that happens to share a title.
Re-run the minimal sequence on the current build and record what happens. If it still fails, the fix did not hold, and the repro is your evidence. If it passes, ask what is different about the new report: a different build, a different account, a different data state, a different path to the same screen. That difference is the lead. Do not simply reopen the ticket and restate the original complaint. Add the new conditions, the new steps, and the new expected versus actual.
Reopened defects deserve honest severity and priority review. A bug that returns after being marked fixed is often more severe than it first appeared, because it suggests a gap in understanding rather than a one-off mistake. Update the affected area, note the regression, and route it through triage again. The ledger should show the history plainly: what was claimed, what was fixed, what came back, and what the current repro proves.
07 Frequently asked questions
How short should a repro be. Short enough that every remaining step is necessary, and no shorter. If removing any single step makes the bug disappear, that step belongs. If removing a step changes nothing, it is noise and should go. Length is not the goal; necessity is.
What if I cannot reproduce the bug at all. Say so clearly and describe what you tried. A report that documents failed attempts is still useful, because it narrows the search. Include the build, environment, and steps you ran, and note that the result was no failure. That tells the next person where not to look.
Should I include a video or screenshot. Visual evidence helps when the defect is visual or timing-dependent, but it does not replace written steps. A recording shows what happened once; steps let someone make it happen again. Use both when the failure is hard to describe in words.
What if the reporter and I disagree about severity. Separate damage from scheduling. Describe the consequence in plain terms and let triage weigh it against release timing and user impact. Disagreement about priority is normal and belongs in the queue, not in the report.
Can I close a defect I cannot reproduce. Not unilaterally. Mark it as unable to reproduce with your evidence, and let triage decide whether to close, request more information, or keep it open. The ledger should record the attempt either way.