3 ms·

In most cases I'd agree. QA teams/testers can be very professional. However, having a team that is responsible for Quality can absolutely lower the quality of

In most cases I'd agree. QA teams/testers can be very professional. However, having a team that is responsible for Quality can absolutely lower the quality of a product. For starters that team is now, at least in terms of perception and more importantly organisational politics, responsible for quality, so by definition others are not held as responsible. That can have all sorts of perverse side-effects. Secondly, if the QA team is not very good, then it's just a time sink. Misreported defects, queries about functionality, increased communication, supposed environmental issues all generated spuriously, then take away time from development and other teams. Lost time is not replaceable, and limited time drives down quality. Lastly, having a separate team lengthens feedback and issues are spotted later in the cycle, this drives quality down too. My preference is always to keep testing within the team, automate it and make the developers think about and appreciate good testing. Good testers, can absolutely contribute, and exploratory testing can be highly valuable, particularly for systems users directly interact with, but they are, in my experience, pretty rare.

switchbak 3y ago
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).

switchbak 3y ago

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).