Building a Test Automation Team from Ground Up

Test automation roles and team structures differ across different Organizations. Should you establish a separate resolute test automation team? Or should one team manage both manual testing efforts and automated testing efforts? Building a productive test automation team requires a good understanding of how to link automation with your business acumen. 

Importance of Automation in Modern Software Development

Agile development demands organizations to run software development and testing activities in parallel. To keep up with the shorter release cycles that come with the adoption of agile development, many organizations are adopting test automation to ensure that every software release follows the anticipated level of excellence.

QA engineers should focus manual effort on testing only those functionalities that cannot be automated and/or exceptional testing use cases that are not good candidates for automation. Automation should take care of those test cases which can often be too monotonous to perform manually.

Challenges in Building a Test Automation Team

• Onboarding skilled resources: The design and execution of the framework must be thoroughly understood by the resources used for test automation. The demand for test automation skills is very high, making it difficult to find and onboard such resources.
• Gaps in roles and responsibilities: To enable every team member to excel, it’s essential to recognize their individual strengths and assign tasks that utilize those abilities. When team members are uncertain about their respective roles and responsibilities, they may inadvertently duplicate work on a project or task. Therefore, it’s crucial to define roles and responsibilities clearly to avoid any confusion or overlap. 
• Test automation team working in silos: A test automation team frequently operates like its own business within the larger organization, which is one of the reasons it is doomed to failure. All team members must work together for successful test automation because quality is everyone’s responsibility.
• Identify the north star metric of your test automation: All of us have some idea of why we need automated testing before we begin. There may be N high-level objectives that can be broken down into smaller, more quantifiable goals, but we need to identify the one indicator that best encapsulates the fundamental benefit that test automation provides and make sure that the entire team should adhere to it.

Prerequisites to Consider before Building a Test Automation Team 

1. Check whether the test cases are written and structured comprehensively enough to test the entire application stack.

The most common pain point that I have seen automation teams tend to experience when they start automation is not having a good set of test cases. Either they get test cases that are not thorough, or they get test cases that are very raw for anyone to execute and understand. In such cases, they automate with whatever is provided to them and then later they get feedback that their test automation is not effective.

Your test suite should be comprehensive enough to cover all modules with different granularity. Still, at the same time, we need to make sure that we do not repeat our test in the layers of automation testing i.e., Unit test Vs API/Service test Vs UI/ E2E test. We should build a strong, rapid, and maintainable test suite: write heaps of small and fast unit tests. Then write some more API/Service tests to cover the Integration part and finally a very few high-level tests that test our application UI from end to end. Also, realistically speaking not everything can be automated, it is especially important to identify what all test cases can be reliably automated.

Benefits of following this practice:

• Maximum test coverage
• Improved testing efficiency
• Effective test automation execution

2. Clearly identify test automation team roles and duties:

Another common challenge that I have seen, and it is to be expected is identifying the roles and responsibilities of team members. Quality is the responsibility of the entire team but there should be a clear bifurcation of what juniors and seniors folks should be doing in the automation team.

You should have a blend of junior and senior folks in your test automation team that should allow all team members to learn and grow while having a cohesive test automation framework in place. The senior team members of the team should be experts in the tech stack and framework that you have designated, and they should be able to build robust, quick, and intelligent test automation frameworks,  build a solid test automation strategy and roadmap,  and they should have an exceptionally good understanding of DevOps methodologies. Whereas the junior team members of your team should be very well acquainted with building test automation scripts. They should spend most of their time maintaining the test automation project and developing & maintaining test scripts.

Benefits of following this practice:

• Reduced duplication of effort
• Team empowerment to perform better and be more focused
• Increase operational efficiency by lowering confusion

3. Determine the goal of your test automation and select the approach/tool/framework accordingly:

Why you want to automate is an important question. Ensuring that the tool, framework, or techniques that you are going to use should be in sync to achieve your test automation goal.

The goal of test automation is fundamental, and it is not an isolated activity. Since every organization has a different goal, here are a few items to consider when choosing which approach/tool/framework to use:

• What is getting automated – APIs/Web/Desktop/Mobile apps?
• Is this a new or an existing project where we have already done some automation?
• Is the test automation suite meant to be integrated with other tools like Test Management, bug tracking, CI/CD, communication channels, etc.?
• The test automation suite is meant to be executed at what scale?
• What is the budget and time duration required to complete this project?
• Are you planning in-sprint automation?

The goal of our test automation should be well-defined, clear, and unambiguous.  Everyone who is involved should know what we want to achieve through test automation.

Benefits of following this practice:

• Increased comprehension and aids in creating a realistic delivery schedule
• Able to meet business goals faster and with fewer obstacles
• Provide emphasis and direction

4. Available resources to train and support our manual QA engineers?

Junior QA team members are not proficient enough and cannot just learn  automation by themselves. Their journey from manual testing to automation testing should be well planned and must be a guided roadmap to living up to the evolved expectations over the years. They need to skill themselves in the programming language that we are using or going to use in our automation framework and only then move to understand the framework concepts, write, and maintain the test scripts, etc. Test automation is a team effort and support is required from all levels. The Dev team can support the testing team by providing secured APIs to interact quickly with backend systems, and for UI automation- by adding locators that make our application simpler to automate. At the same time, the product team can strengthen the test automation efforts by supporting the automation-first approach wherever possible and reviewing the user journeys/scenarios that we are planning to automate.

 Though countless online resources demonstrate how test automation solutions work, I suggest you find people in your organization who can train your manual QA engineers to learn test automation. If you do not have people in your organization, it is better to have an external experienced professional trainer who can impart effective training sessions.

Benefits of following this practice:

• Create a competitive advantage and a talent pipeline
• Increased Employee Retention and Engagement
• Prevent and Resolve Skill Gaps

Ongoing challenges and how to overcome them

I am from that school of thought who believes that test automation coexists well with manual testing, and we do not necessarily need a distinct group of automation staff as the SDET role is much more than just test automation. One unified team of QA engineers should manage both manual testing efforts and automated testing efforts. The unified QA team’s shared expertise is especially important to the success of test automation that also ensures that the test automation team should not work in silos. I concur that if our QA engineers have a solid preference to focus only on manual testing, inspiring and motivating them to adopt automation is challenging but eventually an extremely rewarding one. 

Merging teams such that only a single team does all the manual and automation testing can work well if we can apply the following:

• Provide your team members with the appropriate training (Internal/External) on the new capabilities, features, trends, etc. that should be part of your framework. By doing so, you can close any technical gaps in your team’s knowledge.
• Develop a coherent test automation strategy.
• Preserve a suitable equilibrium between automated and manual tests.
• Make sure there are regular test scenarios and test script reviews. And take the time for code reviews.
• Pick the right set of test cases for the job and perform regular test automation governance.
• Certify that test cases are properly prioritized to start automation.
• Organise paired code reviews with the development and QA team.
• Push at least a few senior members (Test Architect(s)) from the QA team to dedicate their time to completely focus on the stability of the framework, R&D tasks, adding new capabilities, etc.
• Build automation incrementally and add more tests only when you trust on work done so far. In fact, you can start with simple test cases and then move to complex ones.
• Finally, spread enthusiasm and positivity in the team.

Building a test automation team creates some challenges that organizations need to conquer before they can enjoy its benefits of it. Not all QA engineers and teams are the same. It is certainly not easy to get a group of testers on board with the notion of test automation, especially if they have worked on projects for a prolonged time without it and are accustomed to performing the testing manually. There is no wrong way to build an automation team (Unified or Separate) if you plan it well. In the end, we must decide what is best for our project based on Organization culture, cost constraints, resource skills, availability, etc.