When developers keep rejecting your bugs

You filed nine bugs last sprint. Four came back as "cannot reproduce", two as "works as designed", one as "not a bug", and one sat untouched until it was closed for age. One got fixed.

That ratio is a signal, and it is worth reading calmly rather than personally. Rejections have three causes, and the fix for each is completely different. Guess wrong and you will spend a month solving the wrong problem.

Short version

• Rejections come from three sources: weak evidence, wrong severity, or a broken culture.
• Count your rejection reasons for four weeks — the pattern tells you which one you have.
• "Cannot reproduce" is almost always an evidence problem, and it is the easiest to fix.
• "Works as designed" is usually a requirements gap, not a QA failure.
• Severity inflation is the fastest way to lose credibility, and it is silent.
• A culture problem cannot be fixed by writing better tickets. Escalate it as process, not as blame.

---

First, diagnose. Do not guess

For four weeks, log every rejected bug in a spreadsheet with three columns: the ticket ID, the stated reason, and whether you later proved it was real.

You will end up with a distribution. Read it like this.

Do this before you change anything. Most testers assume the culture is the problem, and most of the time the data says otherwise.

---

Cause 1: your evidence

This is the most common cause and the best news, because it is entirely under your control.

A developer rejecting a bug is rarely refusing to work. They spent twenty minutes trying to reproduce it, failed, and moved on. Every gap in your report is time they spend guessing.

The rejection-proof report

A report that survives contact has these parts. Missing any one of them is a common reason for a bounce.

1. The exact URL and environment. https://staging.example.com/checkout, not "the checkout page".
2. The account and role. [email protected], Viewer role, Free plan.
3. Numbered steps starting from a known state. Start from "log in", not from "on the cart page".
4. Expected and actual, stated separately. Both, always, even when it seems obvious.
5. The console error, as text. Copy it, do not screenshot it — developers search their code for exact strings like TypeError: Cannot read properties of undefined (reading 'last4').
6. The failing network request. Method, path, status. "POST /api/v1/checkout returns 500."
7. A screenshot or short video. Annotated, so nobody has to hunt.
8. Frequency. "Happened 4 times out of 5 attempts" is very different from "happened once".
9. Build version and time. 2026.06.28-a7f3c21, 14:32 UTC.

Compare these two

Rejected in eleven minutes: "Checkout is broken. Nothing happens when I click Pay. Please fix."

Fixed the same day: "Checkout fails for saved cards on staging. URL: https://staging.example.com/checkout, build 2026.06.28-a7f3c21, 14:32 UTC. Account: [email protected] (Pro plan, Admin). Steps: 1) Log in. 2) Add any item to the cart. 3) Go to checkout. 4) Choose the saved Visa ending 4242. 5) Click Pay. Expected: order confirmation page. Actual: button spins for ~8s, then the page stays put. Console: TypeError: Cannot read properties of undefined (reading 'last4') at checkout.js:2:41118. Network: POST /api/v1/checkout returns 500, response body {"error":"card_token_missing"}. Frequency: 5 of 5 attempts. Does not happen with a newly entered card. Video attached."

The second is not longer because of effort. It is longer because the information was captured while the bug was on screen.

Why this is hard in practice

The honest problem is that the console clears on reload, DevTools was not open when it happened, and by the time you realise you have a bug, the evidence is gone.

Two things help. The habit: keep DevTools docked and open all day while testing, with "Preserve log" ticked. The tooling: browser-based bug reporting tools such as Crosscheck run in the page and keep a rolling record, so the console output, network requests, screenshot, and environment details are already attached when you report — including the part that happened before you knew there was a bug.

The "cannot reproduce" reply that works

When a bug comes back unreproduced, do not resend the same report. Send the difference.

"Still reproduces for me on build 2026.06.28-a7f3c21. Which build and account did you test with? I am on [email protected] with a saved card. It does not reproduce with a newly entered card, so the saved-card path may be the difference. Video with the console open is attached."

You have given them a hypothesis instead of a contradiction.

---

Cause 2: your severity calls

If the rejections say "too minor to fix now" but you believe the bugs are serious, the argument is about severity. And here is the uncomfortable part: it is often the tester who is wrong, because severity inflation is easy to slip into and impossible to notice from the inside.

How inflation happens

You file a genuinely serious bug as Critical. It gets deprioritised. So next time you file a Major bug as Critical, hoping to be heard. It works once. Within two months, every bug you file is Critical, and the team has learned to read your Critical as "probably Major, maybe Minor".

Now your real Critical is invisible. You have spent the only credibility you had.

Calibrate against the definitions, not your feelings

Two rules end most disputes. No workaround means at least Major. Anything touching money, personal data, or permissions goes up one level.

Argue with reach, not adjectives

Severity arguments are won with numbers, not intensity.

Weak: "This is a huge problem and needs fixing now."

Strong: "This affects every user paying with a saved card. That was 61% of orders last month. There is no workaround inside the flow — the user has to re-enter the card manually, and 3 of 5 testers did not work that out on their own."

If you cannot state who is affected and how often, you are not yet arguing severity. You are arguing preference — and you may want to check whether you have the level right.

Run a calibration session

The most effective single fix: take ten recent bugs to a 30-minute meeting with a developer and a product owner. Everyone rates each one independently, then compare. You will find two or three definitions where you genuinely disagree, and fixing those wordings removes most future arguments.

---

Cause 3: the culture

Sometimes your evidence is good and your severity is honest, and bugs still get rejected. Signs it is cultural rather than technical:

• Rejections have no written reason
• Bugs are closed without the reporter being told
• The same developer rejects everything; others do not
• "Not a bug" is used for things that clearly break the stated requirement
• Bugs found in someone's own code are rejected more often than bugs in shared code
• Testers on the team have quietly stopped reporting small bugs

That last sign is the serious one. When reporting stops, the numbers improve and the product gets worse.

What to do

1. Bring data, not incidents. "Six of my nine bugs last sprint were closed without a written reason, and three of those were later reported by customers." That is a process finding. "Marek keeps rejecting my bugs" is a complaint, and it will be heard as one.
2. Ask for two rules, not a culture change. A rejection needs a written reason, and the reporter gets one appeal to the next triage session. These are small, cheap, and they fix most of the behaviour on their own.
3. Make triage a shared meeting. Fifteen minutes, twice a week, with a tester and a developer present. Most bad rejections happen when one person decides alone under time pressure.
4. Track escaped bugs. Count bugs that were rejected internally and later reported by a customer. Three of those in a quarter changes the conversation completely, and it is not an opinion.
5. Fix your own side first anyway. Even if the culture is genuinely the problem, arriving with excellent reports removes the only counter-argument available.

---

What not to do

• Do not reopen the same ticket repeatedly without adding new information. It reads as pressure and stops working after the second time.
• Do not inflate severity to be heard. It works once and costs you every future report.
• Do not go over someone's head first. Escalate the process, not the person, and only after the two-rule request has failed.
• Do not take a rejection as a verdict on you. Some bugs genuinely are not bugs, and being wrong occasionally is normal. If you are never wrong, you are probably not reporting enough edge cases.

---

Frequently asked questions

What should I do the moment a bug is rejected as "cannot reproduce"? Ask which build, account, and environment they used, and state yours. The rejection is a clue that something differs between two machines, not a judgement on whether the bug exists.

How many rejections is normal? Roughly 10 to 20% of reports being rejected is healthy on most teams. Above about a third, something systematic is wrong — usually evidence. Near zero can also be a warning sign that nobody is checking.

A developer says "works as designed" but the behaviour is clearly wrong. What now? They may be right about the design and you may be right about the user. Move it to the product owner as a question about intended behaviour, not to the developer as a bug. Attach what a user would reasonably expect and why.

Should I write the bug report differently for different developers? No. Write one complete format every time. Consistency is what makes your reports fast to read, and a format that varies is a format nobody learns.

My team has no severity definitions at all. Where do I start? Write four one-line definitions, take them to a 30-minute calibration session with ten real bugs, and adjust the wording where people disagree. That single meeting resolves most severity arguments for months.