When a defect report is rejected, how do not a bug, duplicate, cannot reproduce and works as designed differ?

## Rejection is a decision, not a delete A rejected report still consumed someone's attention and still describes something a person saw. The lifecycle therefore treats rejection as a **transition with a stated reason**, visible to the reporter, reversible on new evidence. Teams that reject silently teach their reporters — testers, support staff, developers on other teams — to stop filing, and the cost of that is invisible until an obvious defect reaches users because nobody bothered. The four reasons below are the standard set. They differ in **what they claim** and in **who is entitled to make the claim**. ## Not a bug The claim: the product did the right thing; the report is mistaken. Typical causes are a misread of the output, a test that asserted the wrong thing, a stale or misconfigured environment, or user error against a documented behaviour. Who may say it: someone who can point at the correct behaviour — usually the assignee, with the reasoning attached. What makes it defensible is the *evidence of correctness*, not the assertion. "Not a bug" with no explanation is the single most common trigger for a rejection ping-pong. ## Duplicate The claim: the failure is real and already has a record. Three details matter: 1. **Direction.** Close the newer report onto the canonical one, and be explicit which is canonical. When the newer report is the better-written of the two, promote it and close the older one instead — the canonical record should be the one an engineer can act on. 2. **Evidence migration.** The second report almost always carries something the first lacked: a different path to the failure, another environment, a clearer log. Carry that across before closing; a duplicate that discards its evidence is a small act of vandalism. 3. **Not-quite-duplicates.** Two reports with the same symptom and different causes are not duplicates. If closing one as a duplicate would let a distinct cause go unfixed when the canonical one is resolved, they stay separate. ## Cannot reproduce The claim is much weaker than teams treat it: *we tried, under stated conditions, and did not see it*. It is a statement about the attempt, not about the product. To be a legitimate resolution it must record the build identifier, the environment, the data used, and how many attempts were made — and it should go back to the reporter before it is closed, because the reporter is the one person who has seen it. Most cannot-reproduce closes are really a mismatch the team has not found yet: different data, different account state, different timing, different locale or clock. A tax-filing wizard that loses the final page only when the submission crosses local midnight will resist every daytime reproduction attempt, and will look like a phantom until someone notices the clock-skew artefact in the logs. A failure seen 3 times in 137 nightly runs is not reproduced by two manual attempts — that outcome was the most likely one even if the defect is perfectly real. Practical handling: ask for the missing dimension rather than closing (exact time, account, data set, build), attach whatever diagnostics would make a recurrence conclusive, and if it must be closed, close it in a way that makes recurrence cheap to spot rather than pretending the question is settled. ## Works as designed The claim: the behaviour is real, intended, and matches the specification. This is the only rejection where reporter and assignee usually agree on the facts and disagree about the design. It therefore routes differently: the decision does not belong to the engineer, it belongs to whoever owns the specification — product, or whoever wrote the acceptance criteria. Two failure modes: - Using it as a shield. "It is designed that way" when nothing was actually designed — the behaviour is simply what the code happens to do. Ask for the specification; if none exists, the argument is really about whether the behaviour is defensible, and that is a product conversation. - Closing and forgetting. When the design is wrong, the right output is a change request or a backlog item that inherits the report's evidence, not a closed defect and a shrug. ## The shape of a good rejection Regardless of reason, a rejection that survives review contains: the reason from the fixed set, the evidence for it, the person who made the call, and a notification to the reporter with a route to disagree. Disagreement is normal and cheap when the process expects it: the reporter supplies the missing dimension, the report reopens, and nobody has to escalate a personal argument. An interviewer asking this wants to hear two things. First, that you know the four claims are genuinely different — candidates who blur *cannot reproduce* into *not a bug* are telling you they close reports to keep a queue tidy. Second, that you treat rejection as reviewable: reasons recorded, reporter informed, evidence preserved.