I'm really curious about the reality of automating QA testing. Lately, I've been seeing a ton of posts claiming that people have "automated 90% of QA" and eliminated manual testing entirely. However, when I talk to these folks, they still have QA teams in place.
Right now, we have three QA engineers supporting a team of 25 developers, and they seem to be constantly overloaded. Bugs keep popping up in production, and our leadership wants to shift towards automating QA instead of hiring more help. I can't shake the feeling that this is one of those theoretical ideas that doesn't really work in practice.
We've implemented some test automation frameworks, but they still require someone to write and maintain the tests. Plus, they often miss those tricky edge cases that only a person could catch, not to mention our integration tests can be very flaky and take forever to run.
So, what's the actual verdict? Can you really reduce staff through automation, or does it just move the workload around? And if you've successfully managed this, what tools or strategies did you use? I'm specifically looking for methods that wouldn't require bringing in a separate automation team, as that defeats the purpose of streamlining.
4 Answers
The hype around automating QA can be misleading. I don't think anyone is actually eliminating QA teams; they're just changing their roles. You can definitely alleviate manual testing burdens if you have solid test coverage. It's more about what your QA team is spending their time on right now. Are they writing test cases, running tests, or sorting bugs? Automation can help with different areas depending on the workload.
Your test pyramid is crucial. If you're heavily weighted with integration tests and lacking in unit tests, that's likely causing the flakiness and slow performance. Balancing the tests properly can make automation much more effective.
Yeah, we're definitely upside down with too many integration tests and hardly any unit testing. That's something we need to fix!
From my experience, QA can't just be an afterthought. Developers need to get involved in the QA process; otherwise, success is pretty limited regardless of your team's size or automation levels. It's not just about having enough people on the QA side, but making sure testing is integrated into the development process.
Having just three QA for 25 developers isn't a great setup. If boosting your QA team isn’t possible, you might consider reducing the dev headcount and hiring QA developers. To build full automation, I’d suggest implementing a policy where no new code gets merged unless it includes automated tests for that feature or fix. We did this with our API tests using Ruby/Cucumber, which worked well for our QAs, and in just six months we managed to cover all service endpoints with automated tests.
Honestly, most of their time goes to manual testing and bug triaging since our test coverage isn't great, so they’re always behind.