You spent time reproducing a bug, writing a careful report, and filing it properly — and then the developer closes it with "Not a Bug." It stings. But how you respond to this moment defines your professional reputation more than almost anything else in the QA role.
Learning Objectives
By the end of this lesson you will be able to:
- Describe the three most common rejection verdicts and what they actually mean
- Apply a requirements-based approach to challenging a rejection professionally
- Distinguish between situations where you should push back and where you should accept
The Three Verdicts
"Not a Bug" / "Works as Designed"
The developer (or product owner) is saying: "This behavior is intentional. It matches what was specified."
This verdict can be:
- Correct — you misunderstood the requirement, or the behavior is genuinely by design
- Incorrect — the specification says otherwise, and the developer misread it
- Ambiguous — the specification doesn't clearly address this scenario
"Cannot Reproduce"
The developer is saying: "I followed your steps and did not observe the bug."
This can mean:
- Your steps were incomplete or environment-specific
- The bug is intermittent (timing, race condition, specific data state)
- The bug was fixed by a related change the developer doesn't know about yet
"Duplicate"
The developer found an existing ticket that covers the same issue. Your report is valid — it's just redundant.
Step 1: Check the Requirements First
Before escalating, disputing, or feeling offended — go back to the requirements document, acceptance criteria, or design spec.
Ask yourself:
- Does the specification explicitly address this behavior?
- If yes, does it support my position or the developer's?
- If the spec is silent on this, that's a documentation gap — which is itself a finding.
If the spec supports your position: quote it in the ticket comment. "Per the acceptance criteria in PROJ-142: 'The form must display a validation error when the email field is empty.' The current behavior does not do this."
If the spec is silent: raise a clarification request with the product owner or BA. This is not a bug until the expected behavior is defined.
Step 2: Strengthen Your Evidence
If the verdict is "Cannot Reproduce," the solution is better evidence, not more arguing.
Add to your report:
- Exact environment (OS, browser version, build number)
- A screen recording showing the reproduction steps and the observed behavior
- Data conditions (what was in the database, what user account you used)
- Frequency ("This happens 8 out of 10 times I try")
A developer who cannot reproduce a bug with your steps and a screen recording has a much harder time dismissing it.
Step 3: Escalate Professionally, Not Emotionally
If you've cross-referenced the requirements and still believe the bug is valid, the escalation path is:
- Comment on the ticket with your reasoning and requirement reference
- Raise it in the next sprint review or team meeting for team discussion
- If unresolved, involve the product owner to arbitrate
What escalation does NOT look like:
- Pinging the developer multiple times on Slack
- Reopening the ticket without adding new information
- Complaining to teammates that "the dev is wrong"
The goal of escalation is to get a decision made, not to win an argument.
When to Accept the Verdict
Sometimes the developer is right.
- If the spec genuinely supports their interpretation, accept it gracefully. "Thanks for the clarification — I misread the acceptance criteria. Closing."
- If the behavior is a genuine design decision (even one you disagree with), log your concern as a UX suggestion, not a bug.
- If the spec is ambiguous and the PO confirms the developer's interpretation, update your mental model and move on.
Accepting a verdict professionally builds more professional capital than fighting every rejection.
Pro Tips
"Not a Bug" is not a personal verdict. It's a statement about a behavior. Don't take it personally. Channel the energy into better documentation next time.
Log ambiguous spec situations. Every time a bug is rejected because the spec was unclear, note it. A pattern of spec ambiguities is a process improvement conversation waiting to happen.
Summary
- "Not a Bug," "Works as Designed," and "Cannot Reproduce" are the three most common rejection verdicts.
- Always check the requirements before responding — they are the neutral ground.
- Strengthen "Cannot Reproduce" cases with screen recordings, environment details, and frequency data.
- Professional escalation goes through the ticket, the team meeting, and the product owner — not through emotion.
- Knowing when to accept a verdict gracefully is as important as knowing when to push back.