3 ms·
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 qua
by 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 agoJust 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.