Defects Product thanks you for (and ones they ignore)
Not every bug earns attention. How I write defect reports that name the user impact, the business risk and the next action, and how I tell when a finding is not a defect at all.
Product ignores defects that sound like taste without consequence. They thank you for defects that name the user impact, the business risk and a clear next action. Most testers learn this the slow way, by watching a sprint’s worth of carefully logged tickets sit untouched while a single line from a customer gets fixed within the day.
The customer’s line had what the tickets lacked: a person, something they could not do, and a cost. A defect report is a request for someone else’s time, and Product weighs it against features that arrive with a business case attached. I have covered for Product Owners, so I have read backlogs from that chair. A ticket titled “Alignment issue on details page” gives you nothing to weigh.
Why Product ignores some defect reports
It is rarely indifference to quality. The report has usually failed in one of a few recognisable ways.
| How the report reads | What Product hears | What it needed to say |
|---|---|---|
| “The button should be on the left” | A preference | Which agreed design it departs from, or that it is a suggestion |
| “500 on POST /orders” | An Engineering matter | The customer cannot place an order, and under which conditions |
| “Sometimes fails to save” | Unconfirmed | How often, for which accounts and with what data |
| Critical, like every other ticket | Noise | A severity argued from the journey it interrupts |
| No request at all | Someone else’s decision | Fix before release, decide or clarify |
The fourth row does the most damage. When every ticket is critical, the label stops carrying information. Product falls back on its own sense of what matters, without the evidence you could have supplied.
What a defect report needs before Product will prioritise it
Three things, and all three fit in the first few lines of the ticket.
User impact. Who is affected, on which journey, and what they cannot do. I write the title in user language when I can: what broke for whom. “Customer cannot pay with a saved card after changing address” needs no translator.
Business risk. What it costs if it ships: lost revenue, a compliance exposure, calls to Support, a poor first impression on a new tenant. I state it as a consequence someone can check, and I say so when I do not know the scale.
The next action. What I am asking for: a fix before release, a decision to defer, or an answer about intended behaviour. A report with no request leaves the reader to work out why it was sent to them.
Steps to reproduce stay short. Severity is argued with journey criticality and never with personal frustration. A typo I find infuriating is still a typo. A quiet rounding error on an invoice is something else, however calm I feel about it.
- Title: Customer is charged twice when they tap Pay again after a slow response.
- Who and where: any customer paying by card on mobile web, at the final step of checkout.
- Impact: two charges for one order. The customer sees a single confirmation.
- Business risk: each case needs a manual refund and is likely to produce a complaint. Scale unknown. I reproduced it three times in five attempts on a throttled connection.
- Asking for: fix before release. If deferred, Support needs a script and Finance a way to spot the duplicates.
- Build and environment: 2.9.0-rc1 on pre-production. Steps and a recording are attached.
When a finding is not a defect
Sometimes the right move is not a defect. A defect says the product contradicts something that was agreed: an acceptance criterion, a signed-off design, behaviour that worked in the previous release. If nothing was agreed, there is nothing to be defective against, and the honest type is one of three others.
- A story, when the behaviour was never specified and someone has to decide what it should be. It goes to refinement with the gap described.
- A question, when I cannot tell whether what I see is intended. It goes straight to Product, and either becomes a defect or disappears once answered.
- An improvement, when the product does what was agreed and I think the agreement could be better. It is logged as low priority, and I do not argue for it in release week.
Forcing everything into “bug” trains people to mute you. It also sends the work to the wrong place. A gap in the requirements logged as a defect lands on a developer who cannot fix it, comes back as “works as designed”, and the conversation about what the user needs never happens. Most of these gaps are cheaper to catch earlier, when acceptance criteria are being written or when the design is compared with what was built.
What to do when Engineering returns your defects
A returned ticket is information. “Cannot reproduce”, “need more detail” and “works as designed” each say that something the developer needed was missing. If it happens often, fix the template and the conversation. Shouting louder changes nothing.
I ask developers what they went looking for and did not find. The answers are usually the build, the environment, the account or data, and what was expected against what happened. Those become required fields. Template work is dull, and it pays: a defect template I introduced cut developer returns by about 40%.
The conversation is the other half. For anything contentious, two minutes with the developer or the product owner before logging is worth more than a long thread of comments afterwards. Often the ticket that follows is shorter, and sometimes there is no ticket, because the two minutes showed it was a question.
The objection: QA should log everything
I hear this from testers more than from anyone else. Filtering findings is not our job, the argument goes, so log it all and let Product sort it out. I do log everything real. What I will not do is give it all the same type, the same severity and the same urgency, because that hands Product an unsorted pile and calls it diligence.
There is a credibility budget here. Each ticket that turns out to matter adds to it, and each one that wastes a reader’s time spends it. The tester whose defects are always worth reading gets a hearing on the day they raise one that should stop a release.
Hygiene matters for the same reason. Close zombies, merge duplicates and keep the board trustworthy, as I describe in Defect backlog hygiene beats writing more cases. A clean backlog makes the good defects visible.
Written this way, a defect is a choice put in front of Product with the cost attached. Fewer findings get logged as bugs and more of them get fixed. The ones that are deferred are deferred by someone who understood what they were accepting.
Questions I get asked
What makes a good defect report for a product owner?
Three things near the top: who is affected and what they cannot do, what it costs the business if it ships, and what you are asking for. Add a title in user language, short steps, the build and environment, and a severity argued from the journey it interrupts. A product owner should be able to decide from the first few lines without opening the attachments.
When should a tester raise a story instead of a bug?
When the product does not contradict anything that was agreed. If behaviour was never specified, someone has to decide what it should be, and that is a story for refinement. If you cannot tell whether behaviour is intended, ask Product a question first. Keep defects for cases where the build departs from an acceptance criterion, a signed-off design or behaviour that used to work.
Why do developers keep returning my bug reports?
Usually because something they need is missing: the build, the environment, the account or data used, or a clear statement of expected against actual. Ask them what they looked for and could not find, and make those fields part of the template. Returns marked “works as designed” often mean the finding was a requirements gap and should have gone to Product.
Filed under Defect management and backlog hygiene. Terms: Defect report.
