When to Reject a Bug (And How to Do It Without Conflict)

Bug rejection is one of the most conflict-prone interactions in software teams. QA files a bug. Developer rejects it. QA feels dismissed. Developer feels hassled. The actual quality decision gets lost in the interpersonal friction.

Done well, bug rejection is a clear, collaborative decision that both parties understand and agree with. Here's when rejection is appropriate and how to do it cleanly.

---

Valid Reasons to Reject a Bug

1. Working as Designed

The behavior is intentional. The specification says it should work this way. The QA engineer either didn't read the spec or the spec and the behavior disagree — which is a spec issue, not a code issue.

How to communicate: "This behavior matches the specification in [link]. The spec says [X]. Would you like to update the spec to change this behavior? If so, this becomes a feature request rather than a bug."

2. Duplicate

The issue is already tracked under another ticket.

How to communicate: "This is a duplicate of #1234. I'm linking and closing this ticket."

3. Out of Scope

The behavior is a known limitation, a third-party system's issue, or a product decision not to fix.

How to communicate: "This is caused by [third-party SDK]. We've documented this limitation in [place]. It's not something we can fix on our end."

4. Cannot Reproduce

Covered separately, but if the ticket has gone through the proper reproduction attempt process and the bug cannot be reproduced: document what was tried and classify appropriately.

How to communicate: "After [specific reproduction attempts], I cannot reproduce this. The ticket is being classified as 'cannot reproduce — monitor for recurrence.' If it appears again, please reopen with additional details."

5. Won't Fix (Risk Accepted)

The bug is real and reproducible, but the fix risk or cost doesn't justify fixing. This requires an explicit business decision.

How to communicate: "This bug is confirmed. The fix requires refactoring [module]. Given the risk of regression in the payment flow, we've decided to accept this as a known issue. It affects [X% of users] in [edge case]. Documenting for future consideration."

---

Invalid Reasons to Reject a Bug

"That's not how users use it." If a real user can trigger it, it's a real bug. User behavior that doesn't match intended use isn't a rejection reason.

"It works on my machine." "Cannot reproduce" has a specific process. This phrase without that process is a dismissal, not a rejection.

"It's by design" — without pointing to where that design is documented. "By design" requires evidence. Undocumented "design" is assumed behavior, not specification.

"This is minor." Severity is an assessment, not a rejection reason. A minor bug is still a real bug. "Low priority" is the right label; rejection is not.

[!WARNING] "Working as designed" without pointing to the actual design document is the most common invalid rejection. If the design exists and the behavior matches it — valid. If the design doesn't exist or doesn't mention this behavior — invalid. QA should push back on undocumented "by design" claims.

---

The Joint Triage Process

Rejection decisions that bypass the person who filed the bug create resentment. The better process:

1. Developer believes the bug should be rejected
2. Developer documents the reason and assigns to QA for review
3. QA reviews: either agrees (closes) or disagrees (discusses)
4. If disagreement: joint triage call, both perspectives heard
5. Decision made with both parties present

This takes slightly more time than a unilateral close. It produces buy-in and prevents the same rejection conversation from happening again on the next similar bug.

---

Documentation Is Non-Negotiable

Every rejection needs a documented reason. "Closed" with no comment is not a rejection — it's a dismissal. The documentation serves:

• Reference for future similar bugs
• Evidence for post-incident analysis if the "rejected" bug later causes production issues
• Trust-building with QA (they can see the reasoning, not just the outcome)

The 2-minute investment in a clear rejection comment is repaid many times in avoided conflict and avoided re-filing of the same issue.