You make some very good points. I've definitely seen organizational dysfunction related to the Quality / QA split of responsibility. Typically this manifests as

You make some very good points. I've definitely seen organizational dysfunction related to the Quality / QA split of responsibility. Typically this manifests as: - an over-reliance on low quality and fragile tests at the highest and least flexible level of the stack. Usually a GUI or browser based tests. - under investment in domain synthesis and learning, and an over-investment in either automated testing or robotically following test plans. - because we've shifted the responsibility and accountability to a different team, the developers may assume that they have a reduced burden to test their work. And you get the typical "throw it over the fence" pattern, with its associated long latencies. - an us vs them mentality, separate management, and isolated silos of communication. The pattern I've advocated for is more like: having an experienced and talented exploratory tester as a core part of a given team. They take full responsibility on deeply understanding the domain, and often become a real expert that can identify domain level misunderstandings and poor mappings on to the solution domain. These issues are amongst the most expensive to fix, and the payback for this level of investment is ridiculously huge. So I wish we had a more distinct term that would help distinguish this older approach of QA (or SQA) with the dysfunctional patterns we've identified from the newer exploratory testing role. Something like "subject matter validator" (naming is hard).