FWIW, I work in the test industry. This is incredibly specific to one way to do QA. Arguably I'd say it's a bad way to do it, much as you can find really bad e

FWIW, I work in the test industry. This is incredibly specific to one way to do QA. Arguably I'd say it's a bad way to do it, much as you can find really bad engineering practice, in which case I agree with you: bad practice is bad practice. :) People complain about how hard it is to hire good developers, and this goes double or even triple for people in the test industry, frankly. So much depends on what the project actually needs. If developers are doing a great job of handling QA-related issues themselves, great. But sometimes you need someone to help you clear out technical debt, rig up some test infrastructure, help refine a release process, etc. And sometimes the risk of regression is so high and the product is so big that you do need an army of testers. Likewise, for any sufficiently large project, having a dedicated person who keeps an eye on the big picture -- a clean & accurate bug DB; tracking customer reports/issues; finding & narrowing bugs -- can be an asset. This goes double when the tester's job is to be a product expert, and when the tester is reasonably technical. And yes testers should be more or less embedded with developers. "Throw it over the wall" is invariably a terrible way to handle releases. Testers should exist to enable deploy early, deploy often, not to inhibit it. And so on. But see above re: hiring good testers. It's hard.