Step 1: Dismiss the wrong goals
It’s not unlikely for your team to be tempted by automation for the wrong reasons. If they are the only structure QA team can justify the hassle with, you probably don’t really need it.
Develop as a tester. Team members that want to grow as specialists deserve all the praise, but automation for the sake of it is not necessarily the answer. Automated tests are just one of the tools that help them find as many bugs as possible in the least amount of time.
Tidy up the project. It could be possible that the team doesn’t comprehend the whole structure of software testing project. Automating everything sounds like a simple way to increase QA coverage and make it robust at that. Alas, automated tests are expensive in the sense that they take a lot of time to write and maintain. You might want to actually make devs and QA specialists spend some quality time to discover blind spots together instead.
Improve “quality”. There is nothing inherently wrong with that goal, but you need to be more specific than that. QA team test preparation takes a lot of time and money, so don’t let them go to waste on a whim. A good example here would be reducing the number of manual tests if your team doesn’t have enough time to start covering more code.
Step 2: Pick the adequate goals
Making the team change the testing structure is a daunting task that works better when formalised. Decide on the goals that you want to achieve so you can track the progress and then celebrate success or identify failure later. Here are some ideas from Alexei Barantsev, one of the creators behind the test automation framework Selenium that we at aqua use.
Execute faster. The less time it takes to run the whole suite of checks, the faster you can deploy the new builds.
Execute earlier. Integrating automated tests into the development pipeline will help your colleagues identify and fix issues themselves, reducing the burden of test automation of QA team.
Execute more frequently. Automated tests can be run after every single commit, which makes spotting and resolving regression much easier.
Execute vaster. Automation tests can indeed increase coverage, especially if you use a test management platform to track manual effort along them
Step 3: Nail automation testing team structure
Junior QA specialists can’t just self-learn themselves into automation gurus — and some companies learn it the hard way. We suggest that you avoid that by revisiting how you view test team structure in software testing. Here’s how the team composition could look based on our experience of test automation on a SaaS platform:
- Team Leader: QA Lead specialist that owns the automation process
- Testers: a mix of Junior/Middle and Senior specialists carrying the workload
- Infrastructure engineers: proven integration specialists maintaining automation framework
There will, of course, be plenty of others that will be involved or directly affected by the work done by the QA team:
- Product Owner might need to increase their availability for QA team to help create exhausting automated tests
- Project Manager has to temper their deadline expectations before QA (hopefully) gets even faster than usual
- Developers should allocate the time to fix issues discover automatically as they prepare the new build, not after receiving bug reports from QA
Long story short, test automation is about both the team and how others interact with it.
Step 4: Trust the process
Now that you have a team, let them draft an automation plan and follow through with it. We’ve mentioned some key hurdles along the way. You may face some of them or perhaps encounter others instead. What matters is you give the automation team the time to work their magic.
As I mentioned earlier, make sure to track progress relative to automation goals that you set. Things going well call for celebration, while issues need to be called out before they are worth the trouble. After all, you do know why you got into automation in the first place.
Test automation is a noble but costly endeavour. You should see if you want it for the right reasons, put a lot of thought into the QA team composition, and make others enable the team. If things go as planned or you stick with them long enough, you may have indeed saved a lot of money and/or made software better.