A separate QA role makes developers slack

We noticed this pattern at customers long before I had a clean explanation for it. The teams with a dedicated QA person, or a whole QA stage, were not the teams that shipped the fewest bugs. Often it was the other way around. As soon as there was somebody whose job was to find the problems, the developers relaxed. Why think hard about the edge cases of this change when there is a gate downstream that is supposed to catch them?

People will tell you that quality is then a shared responsibility between development and QA. In practice shared responsibility, when it is this fuzzy, is no responsibility. The developer assumes QA will catch it. QA assumes the developer thought about it. The gap between those two assumptions is where the incidents live. A team has to know, without any ambiguity, that it is fully in charge of what it delivers. The moment you add a role that implies otherwise, you have taken that ownership away, and you will not get the quality back.

The author knows the dangerous cases

There is a second problem, and it is more practical. The person who wrote the code knows where the bodies are buried. They know which branch they were unsure about, which external call they did not fully trust, which state transition was awkward to get right. That knowledge is the most valuable input you have for testing, and a separate QA function throws most of it away by design, because it tests from the outside.

External testing finds the obvious things. The dangerous cases, the ones that take down production at the worst possible moment, usually sit in the parts of the code the author already felt uneasy about. If you want those covered, the person to cover them is the one who felt the unease, while they still feel it. A tester reconstructing intent weeks later will miss most of them.

But who owns the business perspective?

The strongest objection I hear is about perspective. The claim goes: developers think about code, and QA brings the perspective of the user and the business. Somebody has to ask whether the feature actually solves the customer's problem, not just whether it is technically correct.

I agree that this perspective matters. I disagree about who owns it. A developer taking responsibility for the business usefulness of what they build has always been non-negotiable for me. If a developer on my teams could not explain what business problem a change solved, that was a gap to close. You close it by pairing them with a product person, or by letting the team work the problem together, until they understand the use case well enough to own it. Adding a gate behind them does not close it.

There is a kind of QA-minded person who is good at this: someone who enjoys mapping out every way a complex workflow can be misused, every input a user might throw at it, every order in which steps might happen. That is real skill and you want it on the team. But a good product person has the same instinct and brings the business context with it. So hire that thinking into the team. Do not build a department around it and call it a checkpoint.

You still have to catch what you miss

None of this means you ship and hope. Dropping the QA gate only works if you accept that your team, like every team, will let things through. So spend the effort on detecting a problem in production fast and reacting to it fast, instead of on a person re-checking work before release.

At Frontastic we had no QA team. Developers owned quality end to end. What made that safe was the boring machinery around it: automated checks that ran on every change, enough observability to see when something started behaving badly, and an on-call setup that let us react in minutes rather than the next morning.

With developers generating large amounts of code through large language models (LLMs), this matters even more. The temptation to insert a human gate that "checks the AI's work" is strong, and it is the same mistake in new clothing. The team still owns what it ships, whether a person or a model wrote the line.

Summary

Do not set up quality assurance as a separate activity. A dedicated QA role takes ownership away from the people who write the code, and ownership is what produces quality. Keep the perspective a good tester brings inside the team, and spend your effort on detecting and reacting to production problems quickly. The same argument applies, almost word for word, to code reviews. I'll get to that next.