Should You Have a Dedicated Automation Team Within Your QA Department?

Posted by Israel Felix in AutomationBest PracticesGuest Blog Posts

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.

Consolidating teams

In my experience with large corporations, I have encountered (on more than one occasion) the need to consolidate teams. This is a real challenge. Most of the manual test engineers have been doing what they do for many years, so pushing them toward automation is a challenge for several reasons:

  • They might not have the technical skills needed to automate and/or automate effectively.
  • Mentally, they may not be prepared for the change.
  • Manual testing tends to take highest priority, as the product needs to ship, so automation takes a backseat.
  • They might not be interested in doing automation simply because it was imposed on them.

For automation teams, it is a little different:

  • They already know automation and they can become a great asset as they help their manual counterpart pick up automation.
  • They already know manual testing (they have to do it prior to automating a test case).
  • They tend to use automation to help with the actual testing.

Consolidating teams, and having only one team to do manual and automation testing can work if done right, but it can fall apart quickly without paying attention to details and planning accordingly. Here are a few suggestions:

  • Make sure there is proper cross-training among the engineers.
  • Make sure to allocate time at the end of the release so that the team can wrap up automation.
  • Continue code reviews among the entire team so that everybody can learn and train on standards.
  • Be very patient during the consolidation. It will take time for everybody to become adjusted and comfortable with the new roles.
  • Continue to rely on key people that can help with frameworks and tools, and make sure they have a lighter amount of testing tasks so that they find time to help the rest of the team.

Building the right team

The ideal scenario for any company is to build a team that fits strategy. Plan the process and hire engineers with the right skill set to implement the strategy. Either dedicated automation teams or teams that do both manual and automation can be successful at delivering a high quality product, but the teams need to be created with specific roles in mind. Consolidating teams later on due to a mandate from management is not the best strategy; it will present a new set of challenges that you will need to overcome. But even if late change has to occur, with proper planning, the transition is definitely doable.

The takeaway

Not all QA teams are created equal! We need to adapt to the unique circumstances of each company and create QA teams that best integrate with processes and fit the products we are trying to test. Sometimes you will end up with two teams — one for manual testing and the other for automation testing. At other times, you will end up with one team that fulfills both roles; in this case, I recommend having resources available to support the team by creating libraries, templates, and piloting new tools.

Whatever the makeup of your team, happy testing!

Israel Felix has more than 20 years of experience working in the technology industry serving multiple leadership roles within development and test groups. The last 15 years have been focused on leading key functional, regression, system, API and sanity test in both automation and manual environments - in technologies such as Switching, Routing, Network Management, Wireless, Voice, and Cloud-Based Software. He has also managed large global test groups across US, India, Thailand and Mexico.

Discuss: Should You Have a Dedicated Automation Team Within Your QA Department?
0 Comments

Free Trial

Get access to a free 14-day trial version, or contact Sales for more information.