How QA Talks to Developers: «It's Not a Bug», Priorities and Tone Without War

Finding the bug is half the job. The other half is getting it fixed without turning the work chat into a trench. Communication with developers is exactly where many technically strong testers stumble. Let’s look at how to negotiate rather than go to war.

«It’s not a bug, it’s a feature»

The classic reply you must not answer with emotion («no, it’s a bug!»). Bring the conversation back to an objective anchor:

To the requirement/spec. «The acceptance criteria say X, the behavior is Y.» If there’s no divergence from the requirement — maybe you’re right that it isn’t a defect.
To user expectation. If there’s no spec: «the user enters valid data and gets an error — is that expected?» Often the «feature» fails a common-sense check.
To a decision. If it’s genuinely debatable, don’t play tug-of-war — take it to where the decision is made (PO/analyst): «let’s confirm with X what the behavior should be».

The goal isn’t to «win», it’s to establish: expected or not. Sometimes «not a bug» is true, and that’s fine.

A good bug report removes half the arguments

Most friction comes from bad reports. A good one leaves almost no room for «can’t reproduce on my machine»:

Steps to reproduce — numbered, with concrete data.
Expected / actual — separate and explicit.
Environment — build/version, OS, browser/device, account, data.
Evidence — screenshot, video, log, trace, request ID.
Frequency — always / sometimes (then add under what conditions).

A report without an «expected» isn’t a bug report — it’s a complaint, and it’ll legitimately get bounced.

Severity ≠ Priority

A frequent point of conflict, because two different dimensions get confused:

Severity — technical impact: the app crashed = high, even if one person a year sees that screen.
Priority — how urgently to fix from a business standpoint: a typo on the homepage seen by a million users can be more urgent than a rare crash.

Your lane is to assess severity honestly and describe the impact. Priority usually isn’t decided by the tester alone (PO/lead, considering the business). Don’t push «critical» where it’s technically minor — you’ll erode trust in your assessments.

Tone: «the behavior is broken», not «you broke it»

A bug isn’t an accusation of the developer — it’s a fact about the product. Phrase it neutrally:

✅ «Submitting the form with an empty email → 500 instead of validation.»
❌ «You didn’t check email again, everything’s falling over.»

Facts, not judgments. No «again», «as usual», «you broke». A developer who isn’t attacked fixes more willingly and faster — and you don’t spend your reputation on emotion.

When «it doesn’t reproduce for me»

This isn’t «you’re looking at it wrong». Most often it’s a difference in conditions. Sort it out together:

Compare the environment: version/build, data, feature flags, role/permissions, cache.
Provide exact input data and the account where it reproduces.
Attach video/trace — sometimes it shows the steps differ.
If the bug is intermittent — say so (flaky/race); don’t present it as stable.

A joint stance of «let’s find why it differs» works; «well it works for me / well it fails for me» doesn’t.

Escalation without «tattling»

Order matters more than emotion:

First — directly to the developer, calmly and with evidence.
If you can’t agree on priority/assessment — take it to the lead/PO as a decision to make, not a complaint: «there’s a dispute over severity/priority, we need a call».
Frame the risk, not the grievance: «if we don’t fix it, here’s what the user/business will see».

Escalation is about unblocking through whoever decides, not about «reporting a person».

Choose your battles

Reputation and trust are a limited resource. Don’t throw yourself on the barricade over every typo.

Big risk (data, money, security, a crash) — hold your ground.
Small stuff — log it in the tracker and let it go; revisit if it becomes important.
Someone who argues on substance and on big things carries more weight than someone who fights over every comma.

In short

QA doesn’t «beat» the developer — you jointly decide whether the behavior is expected.
Break «it’s not a bug» with the requirement/user expectation, not emotion.
A good bug report (steps, expected/actual, environment, evidence) removes half the arguments.
Severity (technical impact) ≠ Priority (business urgency); you don’t set priority alone.
Tone: «behavior X is broken», not «you broke it»; facts, not judgments.
«Can’t reproduce» — compare the environment together, don’t butt heads.
Escalate in order (developer → lead/PO) as a risk, not a complaint. And choose your battles.