01 Overview
A bug report is a small piece of technical writing with one job: to let someone who was not there reproduce what you saw and judge what should happen instead. Most reports fail at the second half. They describe the observed behavior in careful detail and then stop, leaving the reader to infer the correct behavior from context, memory, or hope. That inference is where disagreements are born, and it is why so many reports bounce back with a single question: what did you expect to happen?
Spelling out the expected result is not padding. It is the part of the report that turns a complaint into a claim that can be tested. When you write the expected result, you are stating the contract the product is supposed to honor at that moment. A reader can compare the observed result against it and decide, without a meeting, whether the gap is a defect, a misunderstanding, or a deliberate design choice that needs a different conversation.
The expected result also protects you. If you leave it implicit, the first reviewer fills the gap with their own assumption, and that assumption may quietly become the resolution. Writing it down forces the assumption into the open where it can be confirmed or corrected before anyone spends time fixing the wrong thing.
02 What the report is actually claiming
Every defect report makes an implicit argument: the product did X, the product should have done Y, and X and Y are different in a way that matters. The observed result supplies the first half. The expected result supplies the second. Without both, the report is not a claim at all; it is an observation, and observations are easy to dismiss because they do not assert that anything is wrong.
Stating the expected result also clarifies what kind of defect you think you found. A mismatch between observed and expected might be a logic error, a missing validation, a display problem, a race condition, or a documentation gap. The expected result often reveals which of these you mean. If you expect the form to reject an empty required field and it accepts it, you are claiming a validation gap. If you expect a total to include tax and it does not, you are claiming a calculation error. Naming the expectation sharpens the claim and points the reader toward the right part of the system.
Finally, the expected result is where you record your reasoning, not just your conclusion. A short note about why you expected that outcome, such as a link to the specification, a reference to a similar screen, or a plain statement of user intent, gives the reviewer something to evaluate. It also makes the report useful later, when the original context is gone and someone is trying to decide whether the current behavior is still wrong.
03 Severity versus priority
Severity describes how much damage the defect causes. Priority describes when the team intends to fix it. These are separate judgments, and confusing them is one of the most common sources of friction between testers and engineers. A crash that loses a user's work is high severity. A typo in a rarely visited settings page is low severity. Neither of those statements tells you anything about the order in which the team should work.
Priority is a scheduling decision that depends on context the reporter may not have: how many users hit the path, whether a workaround exists, what is already committed for the release, and what the cost of delay is. A high-severity defect in a feature that ships next quarter may be lower priority than a moderate-severity defect blocking a release this week. That is not a contradiction; it is the normal operation of a planning process that weighs damage against timing.
When you write a report, state severity as an assessment of impact and let the triage process set priority. If you have information that bears on priority, such as a workaround or a customer commitment, say so in plain language rather than inflating the severity field to force attention. Inflating severity to influence scheduling erodes trust in the field, and once reviewers stop trusting severity, every report becomes slower to route.
04 Writing steps someone else can follow
Reproduction steps are a recipe, and like any recipe they should assume the reader has never cooked this dish. Start from a known state: which account, which environment, which data, which build. Then list the smallest set of actions that reliably produces the defect. If a step is not necessary to trigger the problem, cut it. Extra steps add noise and make the report harder to verify when someone tries to confirm the fix later.
Write each step as an action with a visible result. Instead of saying to open the settings page, say to open the settings page and note that the theme selector shows three options. That kind of detail lets the reader confirm they are in the same place you were before they continue. When a step involves specific data, include the exact values you used. Vague inputs produce vague reproductions, and a reproduction that only works sometimes is nearly useless for diagnosis.
End the steps with the observed result and the expected result, stated separately and plainly. Keep them short. The observed result is what actually happened, including any error text or visual detail that matters. The expected result is what should have happened, in the same level of specificity. If the expected result depends on a rule, cite where the rule comes from. A reader should be able to finish your steps and know, without asking, whether they reproduced the defect or not.
05 Running the triage queue
Triage is the routing decision that turns a pile of reports into assigned work. A good triage pass asks a small set of questions for each report: is this reproducible, is it a defect or a design question, what is the affected area, what is the severity, and who should own it next. The expected result is what makes most of those questions answerable in a minute or two rather than a long thread.
When a report lacks an expected result, triage stalls. The reviewer cannot tell whether the behavior is wrong or merely surprising, so the report either gets sent back for information or gets parked in a vague state where it ages quietly. Both outcomes cost more than the minute it would have taken the reporter to write one clear sentence. Reports with a stated expectation move faster because the reviewer can compare, classify, and route without reconstructing the reporter's intent.
Triage should also record its own reasoning. When the team decides a behavior is intended, that decision belongs in the report so the next person does not reopen the same question. When the team decides the severity is lower than reported, say why. When the team cannot decide because the expectation is ambiguous, the correct action is to send it back with a specific question, not to guess. A triage queue that documents its routing decisions becomes a reference for future reports about the same area.
06 When a defect comes back
A defect that returns after being marked fixed is not a failure of the process; it is information. The first question is whether the original fix addressed the reported expectation or only the observed symptom. If the report said the total should include tax and the fix made the total display correctly without changing the calculation, the defect will come back the moment the display path changes. Reopening the report with the same expected result, restated clearly, gives the next engineer a better starting point.
Sometimes the defect returns because the expected result was wrong or incomplete. That is a legitimate outcome, and it should be handled openly. If the product's intended behavior differs from what the report claimed, update the report to reflect the corrected expectation and note what changed. A report that quietly changes its claim without explanation is worse than one that was wrong, because it hides the reasoning that future readers need.
When you reopen a defect, include what you did, what you saw, and how it differs from the expectation. Add the new build or environment if it differs from the original. Avoid the temptation to write a fresh report with no link to the old one; the history is part of the value. A reopened defect with a clear expected result and a clear account of the regression is one of the most useful artifacts a team can produce, because it shows exactly where the earlier understanding fell short.
07 Frequently asked questions
What if I do not know the expected result? Say so explicitly and describe what you would need to know. A report that states the observed behavior and asks a specific question about intent is far more useful than one that guesses. The reviewer can then answer the question, and the answer becomes the expected result for the next report.
Should the expected result repeat the observed result? No. They should be distinct statements. The observed result is what happened; the expected result is what should have happened. If they are identical, there is no defect to report, only a question about design or documentation.
How long should the expected result be? One or two sentences is usually enough. It should be specific enough to test and short enough to read. If you find yourself writing a paragraph, you may be describing a specification rather than an expectation, and that is a different document.
Does every report need an expected result? Yes, including low-severity cosmetic reports. A missing space is only a defect if the expected spacing is stated or obvious from a standard. Stating it takes seconds and removes ambiguity for everyone downstream.
What if the expected result changes during triage? Record the change in the report. The history of how the expectation evolved is often more valuable than the final answer, because it explains why the team treats similar behavior the way it does.