If you’ve led or managed QA teams that have included an automation test team, you’ve probably been in a situation where you had to decide whether you should keep them on board. Normally the decision needs to be made when there is a change in leadership, wherein the new management comes with a mandate to consolidate groups and reduce costs. This situation also tends to arise when working with startups or small companies when they are ready to put together or augment their QA teams. So should you have a dedicated automation team?
Typically, there are two camps with regards to dedicated automation teams. There are those who believe that we should have dedicated automation teams, and those who believe that QA engineers should handle manual testing and automation testing. From my experience working in QA within both small and large companies, I almost always prefer to have a dedicated automation team. However, there are a few scenarios where having a QA team that takes on both roles might make sense.
Time to Market
For automation to be done right, it needs to be a full-time job. From developing the framework and creating the libraries and scripts for different platforms to executing and debugging failures — it will all simply consume too much of an engineer’s time and compromise the actual testing and release date. As you already know, time to market and keeping a release on schedule is top priority, so testing needs to get done, no matter what.
If you don’t have a dedicated automation team, automation will most likely suffer as a result of engineers being consumed with manual testing, and reporting and duplicating bugs for Development to fix. If we ask engineers to prioritize automation, manual testing could suffer as a result of engineers spending too much time with automation-related tasks; therefore, they are unable to complete testing on time.
If you decide to have a QA team that fulfills both roles, I recommend two things:
- Have a support team that can help the QA team with their automation by providing libraries and templates. The support team will not be automating features and test cases, so they wouldn’t be considered an automation team.
- Have the QA team primarily automate acceptance test cases, and wrap up the remaining automation after the product is released.