01 Overview
A defect report is a claim about the product, not a claim about the tester. That distinction sounds small, but it changes almost everything about how the report should be written, read, and acted on. When a tester files a bug, they are describing something they observed in a specific build under specific conditions. They are not, and cannot be, the final authority on how much that observation matters to the business. Severity and priority are different judgments made by different people for different reasons, and confusing the two is one of the most common sources of friction between testers and engineers.
This article is about the craft of separating those judgments cleanly. It covers what a report is actually asserting, why severity and priority diverge, how to write steps that survive a handoff, how a triage queue should run, and what to do when a defect bounces back. The goal is not to make testers passive. Testers should absolutely argue for severity when the evidence supports it. The goal is to keep the tester's voice strong on the question they own, which is what happens and how bad it is, while leaving the scheduling question to the people who own the roadmap.
Treat this as guidance for everyday practice, not as a policy document. Teams differ in size, risk tolerance, and release cadence. The principles here are meant to travel across those differences without pretending every shop works the same way.
02 What the report is actually claiming
Every well-formed defect report makes a small number of factual claims. It claims that a particular build, in a particular environment, produced a particular observable result. It claims that the result differs from an expected result, and it usually claims that the difference is reproducible under stated conditions. Those are the claims a tester can defend with evidence. Anything beyond that, such as how many customers will hit it or how much revenue it will cost, is an inference, and inferences should be labeled as such.
This matters because reviewers read reports quickly and tend to treat confident language as established fact. If a report says the checkout is broken, a reader may picture a total outage when the tester actually saw one payment method fail on one browser. Precision protects everyone. State the observed behavior, state the expected behavior, and state the conditions. If you believe the impact is broad, say what evidence supports that belief and what would confirm or refute it.
A report is also a claim about scope. It should make clear whether the defect affects one user, one account, one tenant, one region, or everyone. It should say whether data was corrupted, whether a workaround exists, and whether the failure is intermittent. Those details are what let a reviewer reason about severity without having to guess. When the claim is narrow and well evidenced, it is easier to trust, and easier to act on.
03 Severity versus priority
Severity describes how much damage the defect does when it occurs. It is a property of the defect and the product surface it touches. A crash that loses a user's work is severe. A cosmetic misalignment is not, even if it is embarrassing. Severity should be argued from evidence about behavior and impact, and it should be stable across releases unless the behavior or the surface changes. If the same defect appears in a payment flow and in a settings label, the severity is not the same, because the damage is not the same.
Priority describes when the team intends to fix the defect. It is a scheduling decision, and scheduling belongs to the people accountable for the release. A low-severity defect in a headline feature may be high priority because it damages trust at a critical moment. A high-severity defect in a deprecated path may be low priority because the path is being removed next sprint. Neither of those outcomes is a judgment about the tester's competence. They are judgments about the roadmap, the risk budget, and the cost of delay.
The friction usually starts when a tester writes priority into the report as if it were a fact. It is better to state severity, state the impact evidence, and let the triage group set priority. If you have a strong view, express it as a recommendation with reasoning, not as a verdict. Reviewers can accept or reject a recommendation without feeling that they are overruling the person who found the bug. That keeps the relationship collaborative and keeps the report focused on what the tester actually observed.
04 Writing steps someone else can follow
Reproduction steps are the part of the report most likely to be skimmed and most likely to be wrong. The test is simple: can a different person, on a different machine, follow your steps and see the same result without asking you a question? If not, the steps need work. Start from a known state and say what that state is. Include the build or version, the environment, the account or role, and any data setup that matters. Then list the shortest sequence of actions that reliably triggers the problem.
Resist the urge to narrate everything you did during the session. Exploratory work is valuable, but the report should contain the minimal path, not the full journey. If the defect only appears after a specific sequence, such as creating an item, editing it twice, then deleting it, that sequence is the core of the report and should be stated plainly. If you are not sure which step is essential, say so and describe what you tried. Honest uncertainty is more useful than a confident but inaccurate recipe.
Include what you expected and what you observed, in that order, so the gap is obvious. Add any evidence that helps, such as logs, screenshots, or a short recording, but do not rely on attachments to carry the explanation. A reader should understand the defect from the text alone. Finally, note whether the issue is intermittent and how often you saw it. A defect that reproduces once in twenty attempts is a different problem from one that reproduces every time, and the steps should reflect that reality.
05 Running the triage queue
Triage is a routing decision, not a debate about whether the tester did a good job. A healthy queue moves fast: each report gets read, classified, and sent somewhere with an owner and a next action. The output of triage is not a feeling about the bug. It is a decision about who will look at it, when, and under what conditions it will be reconsidered. Reports that leave triage without an owner tend to rot, and rotting reports are worse than rejected ones because they create false confidence that someone is handling them.
A useful triage session separates three questions. First, is this a real defect, a duplicate, expected behavior, or a request for a change? Second, what is the severity based on the evidence in the report? Third, what priority does the product owner assign given the current plan? Keeping those questions distinct prevents the common failure where a low-priority decision gets misread as a low-severity judgment. Write the answers down. A short note explaining why a defect was deferred is worth more than a silent status change.
Triage also needs a definition of done for each outcome. Accepted defects get an owner and a target. Deferred defects get a trigger that will bring them back, such as a release milestone or a related change. Rejected defects get a reason the reporter can read and respond to. Duplicates get linked to the original so evidence accumulates in one place. When the queue has these habits, reporters learn what a good report looks like, and reviewers spend less time reconstructing context.
06 When a defect comes back
A defect that returns after being closed is not automatically a failure of the original report. Software changes, environments drift, and fixes sometimes address a symptom rather than the cause. The useful response is to treat the return as new information. Reopen with a fresh observation: what build, what environment, what steps, what result. Link the original report so the history is visible. If the behavior differs from the first occurrence, say how. That comparison is often the clue that leads to the real cause.
It helps to distinguish between a regression and an incomplete fix. A regression is behavior that worked before and stopped working after a change. An incomplete fix is a case where the original defect was narrowed but not eliminated. Both are legitimate, and both deserve a clear description rather than a tone of blame. If the original report was vague, the return is a chance to tighten it. If the original report was precise and the fix missed, the return is evidence that the fix needs another look, and the report should make that easy to see.
Repeated returns are a signal about the process, not just the defect. If the same area keeps producing reopened bugs, that is worth raising in a retrospective as a question about test coverage, review depth, or the stability of the surrounding code. The goal is not to assign fault. The goal is to shorten the distance between finding a problem and understanding it well enough to fix it for good.
07 Frequently asked questions
Should a tester ever set priority? Testers can and should recommend priority when they have context, but the decision belongs to the people accountable for the release. A recommendation framed as reasoning is welcome. A priority asserted as fact tends to create friction and is easy to dismiss.
What if the team disagrees with my severity? Ask what evidence would change their mind, then go find it. Severity arguments are won with reproducible behavior and clear impact, not with volume or repetition. If the disagreement persists, document both views in the report so the decision is visible to whoever revisits it later.
How much detail is too much? Enough detail that a stranger can reproduce the defect, and no more. Extra narrative slows readers down and buries the signal. If you need to explain your exploration, put it after the minimal steps, clearly marked as context.
What about defects nobody can reproduce? Keep the report open with the conditions you observed and mark it as intermittent. Unreproducible reports are still valuable if they are honest about what is known and what is not. They become harmful only when they are written as certainties.
Who owns the report after triage? The assigned owner does, but the reporter still owns the accuracy of the original claim. If new evidence contradicts it, update the report. That habit keeps the ledger trustworthy for everyone who reads it later.