I'm really curious about the practical side of automating QA testing. There's a lot of chatter on LinkedIn about companies claiming they've automated 90% of QA and no longer rely on manual testing, yet when you dig deeper, many still have a QA team.
Currently, our team has three QA engineers working with 25 developers, and they are overwhelmed with issues. Leadership believes automating QA is the solution instead of hiring more staff, but I wonder if this is realistic or just a pipe dream. I've seen various test automation frameworks in use, but they still require someone to write and maintain the tests, and they often overlook edge cases that only a human can catch. Plus, we struggle with flaky integration tests that take an eternity to run.
So, what's the real deal here? Is it possible to reduce our QA headcount through automation, or does it merely shift the workload elsewhere? If anyone has made this work, I'd love to hear what tools or strategies you implemented!
2 Answers
Reducing the number of QA testers by relying completely on automation isn't straightforward. It usually requires significant upfront effort to build the automation framework, potentially taking years. You can end up with a team that automated themselves out of a job, only to be tasked with maintaining the automation tools instead. Focus on improving your test performance, especially for integration tests, as it can noticeably boost the team's productivity.
It's essential to clarify what you mean by QA. Developers should ideally create robust automated tests for core business logic, but true exploration and testing user experiences still need human input. Sometimes, the term QA encompasses too many roles and issues that should have been caught during development.
Absolutely! Many bugs slip into production due to insufficient specifications or the dev team not implementing enough validation tests. It’s crucial to empower developers to take ownership of testing their features instead of relying solely on QA.