3 ms·

I don't see how having a QA team can actually result in worse quality though. Even for your "throw garbage over the fence" (something I've seen first-hand actu

• YZF 3y ago
  The problem is that these are systems. I.e. you're right that in a given system if all else is constant the presence of some QA/testing step should improve quality. But everything else is not constant. But yeah, point taken on the bike helmet arguments, though I think that's a little more clear cut. I think QA (manual software testing by professional testers) has an important role in producing quality software but there are organizational corner cases where the idea of "QA" in software promotes the wrong thinking/approach to quality that results in an overall poor outcome. Quality in software starts before a single line of code is written and has to be in mind throughout the development process so you shouldn't fall into a trap that somehow slapping "Quality Assurance" on top of bad engineering can create quality after the fact.
  • shiroiuma 3y ago
    Just because some people get the wrong idea when something exists, doesn't mean the existence of that thing is an actual problem or detriment. It's true, slapping "QA" on top of bad engineering isn't going to create quality. However, "having quality in mind throughout the development process" isn't going to guarantee it either, especially in a large and complex codebase with modules from many different teams. A QA org is useful for doing things like full-system testing, which can catch bugs that those individual teams might miss because they aren't testing the entire system. It's also useful to have dedicated testers because they'll test things out in ways the devs never thought of. Again, this isn't a replacement for quality engineering at the outset, but that's a management problem.
• NomDePlum 3y ago
  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).
• drewcoo 3y ago
  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.