Building a Testing Team | Automation Tester Roles and Responsibilities

There is no shortage of discussion in the software industry about who should own the responsibility for designing, creating, and maintaining test automation. Automation roles and team structures vary across different companies, teams, and development scenarios. The concern for test automation roles tends to elevate when startups move into a growth spurt, or when a development team needs to increase the size of the QA team. You’ll face the question sooner or later. As tools and applications become increasingly complex, it will serve you well to consider how best to organize testing staff: Should you organize a dedicated test automation team, and how should it function?

Generally, there are two schools of thought on dedicated test automation teams: those who advocate for a distinct group of automation staff, and those who believe that testers and QA engineers should manage both manual testing and automated testing. Those who’ve been working on smaller teams often change their thinking as complexity increases. A growing application, integration challenges, newer technologies, and a large test suite are factors that will induce a team to reconsider if it’s sensible to devote some resources exclusively to testing automation.

Facing the challenges of test automation

Recently in the Functionize blog, we have written on both the technical and organizational challenges to test automation. If you’re ready to face those challenges, it’s important to realize that there are also challenges to building a test automation team—especially if the testing subject is a large application that has little or no automation in the development pipeline.

Elon Musk, CEO of the automaker Tesla, concedes that he relies too much on automation, way too early: “You really want to get the process nailed down and then automate, as opposed to assuming you know what the process will be, then automating that,” he said in an recent interview with the Wall Street Journal.  

While it’s important to know what to automate, software teams will eventually need some degree of test automation—and decide how to partition the responsibilities.  

In this article, we look at major factors that go into the decision to form a separate automation team—especially duplication and a cohesive testing apparatus. We also provide guidelines for forming an automation team and review a number of best practices. 

Most teams have developers writing software and running unit tests to get immediate validation on their code. Simultaneously, QA testers write test code to confirm unit tests and validate all integrations and perform comprehensive testing. This arrangement will work well while the application is simple and small. As functionality grows in volume and complexity, the serious questions must be answered. The first is: Is there excessive test coverage duplication? Also, it’s important to ask: Is there a cohesive structure in the test suite—throughout the entire stack?

You can find more questions in this article: "Selective QA Interview Questions for Managers to Ask".

Eliminating duplication

This is a perpetual challenge for all software development teams. To address duplication, it’s important to recognize the root causes. If two different groups have ownership for different sets of tests, a natural division will exist—which will result in some degree of duplication. Implicitly, developers assume that testers know what is necessary to test in addition to their unit tests. And, of course, the testers assume that developers are testing “the basics”.

While this initially seems to be a sensible approach, these general dispositions effectively serve to erect a wall between the two sub-teams. The result is that testers spend much of their effort seeking to understand what is best to add to the test suites, and also augmenting and automating those test suites. This seems to be good practice since the testers are doing their job writing tests. But, for too many teams, there is an opportunity cost to this narrow scope of the effort.  

There are other essential QA tasks, such as collaborating with business/functional analysts to shape and refine use cases, performing deliberate exploratory testing, and engagement with the product owner to consider any feedback. Without participation in these other valuable tasks, the QA team spends way too much effort on one side of “the wall”. Among other issues, this results in unnecessary duplication of testing efforts that are done by both the developers and the testers.  

Another problem is that testers move blindly forward to create the QA verification layer without investing valuable time to acquire in-depth knowledge of the tests that the developers have built. This is another major source of duplication and wasted effort.

Pursuing a cohesive testing apparatus

In deciding whether it’s best to dedicate specific team members to testing automation, another important question to ask is: Are the test suites structured cohesively in support of the entire application stack? The team dynamics given in the previous section often result in an organization in which two subteams are contributing separately to a single codebase. If both subteams have adequate skill levels and experience in working with code, then it’s feasible for one or several team members to take on responsibilities for integrating testing efforts, tests, and testing resources. This dedicated automation team can work toward better automation and minimizing the duplication of testing effort and the overall time needed for testing.

Automation tester roles and responsibilities

There are many challenges in building a robust testing infrastructure since the application undergoes constant change. The developers change and augment the source code in response to new use cases and product requirements. Any responsible development team will view the source code as a high-value repository that must be carefully managed and maintained. Similarly, tests and test code should be treated with equal care. Developers and their managers acknowledge that a high degree of discipline is necessary to build feature-rich, high-quality software. It is critical to cultivate and maintain the same mindset in the QA team. Generally, these guidelines are ideal for cultivating a solid automation team:

• A test automation engineer should have essential skills to work production code, as necessary.
• A team member (developer or tester) should only modify production code if s/he has the skills to automate tests, as necessary.
• If there is a deficiency in either of the above, then that team member should pair with a mentor who can help attain this level of proficiency.
• Eventually, the entire team must collectively make contributions and assume full ownership of the test code, not certain individuals or disciplines within it.

This is ideal and can be difficult to implement for many teams that don’t already have it in place. At a minimum, any existing test automation team must operate by these guidelines in order to achieve success in the long run.

Time to Market

In growing teams, successful test automation requires a significant amount of effort—and should probably become a full-time job for at least one team member. There is much work to be done for validating all of the features, integrations, and systemic functionality. When an application grows, it becomes a job in itself to build a test framework, maintain assets, and manage a continuous stream of changes. Meeting delivery schedules with high-quality products requires that the team make it a top priority to ensure comprehensive, integrated testing. This is simply non-negotiable. It is also vital to invest significant effort to eliminate duplication.

If your application has grown in complexity and you haven’t formed a dedicated automation team, then the automation is unlikely to get done. It certainly won’t be done nearly as well as it could be. That’s because testers will tend to keep their focus on manual testing, manually identifying bugs, and excessive duplicate bug reporting. Conversely, asking the same team of testers to prioritize automation will likely result in a decrease in the efficacy of manual testing because creating a capable test automation infrastructure is challenging. 

If you find that you need to have the QA team manage both roles simultaneously, it is perhaps best to engage a support team that will provide libraries and templates that the QA team can use in its automation efforts. Since the support team won’t be automating tests, they won't be part of the automation team. It’s also good to direct the QA team to focus primarily on automating acceptance tests and focus on other automation tasks following the next product release.

Cultivating an automation team

If your testers have a strong orientation to focus on manual testing, encouraging them to embrace automation is challenging because:

• They likely don’t have the skills to effectively automate.
• They may lack motivation.
• The entrenched mentality may be that manual testing must always take the highest priority. Since the product must ship on time, any thought of automation will naturally be a low priority.

Consolidating teams such that only one team does all the manual and automation testing can work well if care is taken to monitor it all very closely. But it can easily collapse. If it proves to be impracticable to devote some staff entirely to test automation, perhaps you can implement the following:

• Ensure there are solid testing reviews and cross-training among the developers and testers.
• Allocate enough time following the release for completing automation that corresponds to that release.
• Conduct paired code reviews with developers and testers.

If possible, encourage at least one QA team member to devote partial time to focus on frameworks, tools, and cross-pollination. Reduce their manual/functional testing load so that they can devote valuable time to automation.

As the company grows, work to build a team that aligns with strategy, improves quality, and testing performance. Increasing scale and complexity are really impossible to do without automation. As you grow the team, work hard to improve your processes and hire some testers that have automation skills.

The takeaway

Not all QA teams are alike. It’s necessary to adapt to company culture, resource availability, budget constraints, and different application types. Many teams have to work through a transition period of having two groups—one for manual testing and the other that focuses on automation. If you keep your eye on the ideals, you can eventually cultivate a team of testers that are all fairly proficient at some level of automation and test code maintenance.