5 ms·
Strongly disagree with the literal premise of this post. The idea of having a separate team with the mandate to “ensure quality” was always ridiculous. Occasion
by natbennett 3y ago
Strongly disagree with the literal premise of this post. The idea of having a separate team with the mandate to “ensure quality” was always ridiculous. Occasionally it was helpful by accident but it was always ridiculous. “Quality” isn’t something you can bake in afterwards by testing a bunch.
Getting rid of everyone with testing expertise, and treating testing expertise as inherently less valuable that implementation expertise? Sure, you could convince me that was a bad idea.
- spinningD20 3y agoDoing every quality activity "after the fact" I agree is the issue. That's the root of the problem you're seeing, not that there was a separate quality team.
- natbennett 3y agoIt’s not the “separate” part that I think is ridiculous. It’s the fact that the team is named “quality assurance.” It relies on a metaphor from manufacturing that’s entirely inappropriate for software. If you want to call it “Testing and Exploration” you’d get no argument from me. (Though I do think you’ll find that team is hard to staff.)
- spinningD20 3y agoI'd call it something like "Risk analysis, identification and mitigation group"