I'm seriously curious about the claims I see on LinkedIn where people say they've "automated 90% of QA" and have "eliminated manual testing." It seems like every post features someone talking about how they did this, yet when you dig deeper, many still have a QA team.
In my case, we have three QA engineers supporting a development team of 25, and they're completely overwhelmed. Despite their efforts, we're still facing a lot of bugs in production. Leadership is pushing for automation of QA processes instead of hiring more staff, but I'm doubtful that this can actually lead to a reduction in headcount.
While we have some automation frameworks in place, they still require human oversight for test writing and maintenance, and they often miss those tricky edge cases. Additionally, our integration tests are inconsistent and take a long time to complete.
So what's the reality here? Can automation really replace the need for more QA personnel, or am I right to think it's just redistributing the workload? And if anyone has successfully managed this, what tools or strategies did you use? I'm not looking for ideas that involve hiring an automation-focused team, as that kind of defeats the purpose!
5 Answers
Our organization shifted most testing responsibilities onto automation, but we still maintain some QA staff. They focus on exploratory testing instead of performing manual test cases. This shift required a cultural change and a commitment to improving practices throughout the company, including having developers take responsibility for testing their own code. Automation does require an initial investment, but the long-term benefits in quality and efficiency can be significant.
Many companies have moved towards integrating QA functions into the development process itself. There shouldn’t be a separate QA silo; instead, everyone involved should be responsible for testing and quality. This approach leads to better outcomes because those developing the software understand best how it should work. Plus, frequent integration and automated tests can help minimize bugs before reaching production.
When you refer to QA, it’s key to clarify what you mean. If you’re talking about automated tests for business logic, that should already be a standard practice among engineers. But if you mean user experience testing or exploratory testing, that’s something that cannot be easily automated. Often, problems with QA stem from deeper engineering issues rather than the QA process itself.
This hits the nail on the head. The real problem might be a lack of specifications or sufficient testing before merges. Focus on improving development practices first, then augment with automated tests.
It's tough to reduce headcount in a small QA team just by automating testing. Achieving effective automation is a big investment of time and resources. Usually, the QA team ends up needing to maintain the automated tests instead. However, if you put in the effort to enhance your testing processes—especially integration tests—you’ll likely see productivity gains.
In our team, we brought in a QA automation engineer to develop an automated testing suite for our web application. We also kept a couple of QA folks for manual testing of edge cases until the automation was more reliable. This structure allowed us to manage testing effectively with just three QA members for a team of 40 developers, whereas before, we'd have needed a lot more people without automation.
Exactly. If bugs are reaching production, it raises questions about the developers’ testing practices. The solution might be to ensure developers create more tests for their features rather than relying solely on QA to catch bugs. Implementing robust integration tests before code goes to production could help eliminate problems at the source.