‘It’s tested, it’s ready.’
I used to take that sentence at face value. Then I spent a few years watching what it actually meant in practice, and it was almost never the same thing twice.
Sometimes it meant ‘I ran it once on my machine and it didn’t crash.’ Sometimes it meant ‘the unit tests pass.’ Sometimes it meant ‘I tested the happy path because the ticket didn’t mention anything else.’ Every one of those is a legitimate thing to have done. None of them is what most people hear when someone says ‘tested.’
That gap, between what a developer means by ‘tested’ and what QA (or a PM, or a customer) assumes it means, is where most of the friction I’ve seen between QA and dev teams actually comes from. Not laziness. Not carelessness. A word doing too much work.
The Missing PR, Revisited
I’ve written before about a case where a feature got tested locally, marked done, and quietly never made it to production because the actual deployment step got skipped. That incident looked like a process failure (no PR, no pipeline), and the fix was procedural: checklists, definitions of done.
But underneath the process gap was a communication gap. The developer believed the feature was ‘tested and done.’ I believed that meant it had gone through our normal path to production. We were both right about our own half of the sentence and wrong about the other half, and neither of us said the quiet part out loud until a customer did it for us.
Unclear Requirements Are the Same Bug, Earlier
The other place this shows up constantly is requirements. A ticket says ‘add validation to the signup form.’ A developer implements validation for the fields that seemed obviously important. QA tests against a mental model that includes five more edge cases nobody wrote down. Now there’s a disagreement about whether the feature is ‘done,’ and it looks like a testing dispute when it’s actually a requirements gap that testing simply surfaced first.
QA gets blamed for ‘finding too much’ or ‘being too strict’ in these situations more often than the actual root cause, an underspecified ticket, gets addressed. That’s backwards. A tester surfacing an unstated assumption is doing the job correctly. The fix isn’t a softer tester. It’s a sharper ticket.
The One Question That Actually Helps
I stopped trying to resolve this after the fact, arguing about whether something ‘counts’ as tested, and started asking one question before a ticket is ever marked done:
‘What exactly did we test, and what did we deliberately decide not to test?’
Not ‘is it tested.’ That question invites a yes/no answer that hides all the interesting information. This version forces a real answer, because ‘deliberately decide not to test’ has to be filled in with something specific, and specific answers are where the actual gaps show up.
Sometimes the answer is completely fine: ‘we didn’t test the admin panel because this change doesn’t touch it.’ Great, that’s a documented, intentional scope decision. Sometimes the answer reveals the whole problem: ‘we didn’t test what happens on a slow connection because nobody thought about it.’ Also great. Now it’s a known gap instead of a silent one.
What Changed When We Started Asking It
The tone of conversations shifted first. ‘Is this tested?’ sounds like an accusation, or at least like a checkbox someone is trying to avoid. ‘What did we deliberately not test?’ sounds like two people building a shared picture of risk. It’s a small wording change, but it moves the conversation from defensive to collaborative almost immediately.
It also made scope decisions visible instead of implicit. Before, an untested edge case just… didn’t get tested, silently, and nobody found out until it broke. After, an untested edge case became a sentence in a PR description or a ticket comment: ‘not covering X in this pass, tracked separately.’ Same amount of testing happened in either case. Only one of them lets anyone downstream make an informed call about the risk they’re accepting.
This Isn’t About Trusting Developers Less
I want to be clear about what this isn’t. It’s not a QA gatekeeping tactic, and it’s not built on an assumption that developers are cutting corners. Most of the ‘it’s tested’ gaps I’ve run into came from competent people who tested exactly what they thought was relevant. The problem was never their diligence. It was that ‘tested’ without a scope attached is a word with no fixed meaning, and two reasonable people can fill it in completely differently without either one being wrong.
Adding the scope back in (what was covered, what wasn’t, and why) doesn’t slow anyone down much. It costs one extra sentence. What it buys back is that when something does slip through later, the conversation is ‘we knew we weren’t covering that, here’s why’ instead of ‘wait, I thought you tested this.’
Final Thought
Most of the QA-versus-dev tension I’ve seen in five different teams traced back to the same root: an unscoped claim of ‘tested’ standing in for a hundred small decisions nobody wrote down.
You don’t fix that with more process, more tooling, or a stricter QA gate. You fix it by asking a slightly better question, at the one moment where the answer still matters: before the ticket closes, not after production finds the gap for you.