A developer rejects your bug as 'works on my machine' or 'not a bug'. What do you do?

My aim is to find out what is true, not to win the argument. I first check whether I was wrong, then close the gap with evidence, and if the disagreement is really about what the product should do, I take it to the person who owns that decision. The two rejections need slightly different handling.

“Works on my machine”

This means we are not observing the same system. I would:

1. Re-test on the latest build in the shared environment. It may already be fixed, or it may be a regression introduced later.
2. List the differences between my setup and theirs: environment (local vs staging), build, browser and version, user role and permissions, feature flags, locale and time zone, test data, cache or service worker state, network conditions.
3. Narrow it down. Try their browser, a fresh profile, a new user, a different account. Often the trigger is a specific data condition, such as a customer with no address or a product with a null price.
4. Attach objective evidence: a video, the failing request and response from DevTools or a HAR file, console errors, server logs or a trace or correlation ID so they can find the exact request in observability tools.
5. Pair for ten minutes. Reproducing it together on a call or at my desk resolves most of these faster than ticket comments.

If it is genuinely intermittent, I record the frequency (for example 2 failures in 20 attempts) and the conditions, and treat that as information, not as a reason to close.

“Not a bug” or “as designed”

This is a disagreement about expected behaviour. I would:

• Point to the source of truth: acceptance criteria, specification, design file, previous behaviour, or a comparable feature in the product.
• If there is no clear source, describe the user impact (“a customer who does X loses their draft”) rather than my opinion.
• Ask the product owner to decide. Neither the tester nor the developer owns product behaviour. If the PO agrees it is intended, I close it and, if useful, suggest a documentation or UX improvement as a separate item.

Tone and process

• Keep comments factual and neutral; describe behaviour, not people.
• Do not inflate severity to force attention.
• If this happens often, look at the cause: unclear acceptance criteria (push for examples in refinement), environment drift (push for reproducible environments), or weak reports (improve the template).

What interviewers look for

• Self-check first: willingness to be wrong.
• A systematic search for environment and data differences.
• Evidence beyond screenshots.
• Correct escalation path to product for behaviour disputes, with a collaborative tone.

Common mistakes

• Reopening the ticket repeatedly with “still happening” and nothing new.
• Escalating to managers before trying to reproduce together.
• Accepting “not a bug” when it contradicts written acceptance criteria.