As already mentioned by GP, reliance on someone else to catch bugs can mean devs don't pay as much attention. The old saying is that "you can't test quality in,

As already mentioned by GP, reliance on someone else to catch bugs can mean devs don't pay as much attention. The old saying is that "you can't test quality in," devs have to code it in. Someone else doing your testing also encourages a false confidence in the tests - danger zone! QA tends to make iterations slower. At the very least, there is some added step with added handoff. That's assuming there's not a lot of back-and-forth between QA and dev. Worse, they often add special test environments (with potential problems) and test passes that take a long time, so even slower still. There's also slowdown due to the Brooksian "Million Man Month" problem. If you have a team that's having problems hitting a schedule, adding team members isn't going to fix it. And there's the fact that the only bugs that matter are the ones customers see. More so, the bugs that impact customer use. Customers always seem to find those bugs no matter how much QA you do. And QA gumming up triage processes and filling backlogs with real "bugs" that no one cares about doesn't help anything. I could go on but this is long-winded enough. IMO, the way QA has been done in the past completely justified the move to eliminate QA a decade or so ago. That doesn't mean there can't be value in it. It does mean that it can't gatekeep or even slow down progress. QA needs to be committed to shipping product and trying to prevent customer-impacting bugs.