Gaining traction on your new automation efforts can be a challenge, especially when your team is new to the art. Teams can stall due to lack of time, no overall direction, or knowledge paralysis. But you can solve this roadblock by temporarily bringing on a developer.
The Problems
I inherited a team that had been rooted in manual testing and was in the process of adapting automation practices. There are normally 1-2 engineers per scrum team, but they had recently become shorthanded due to a couple of promotions out of the team.
The team began to stall in its automation efforts due to:
Lack of training – The main person leading the training had moved on.
Lack of time – The reduction in resources caused many on the team to perform double- duty while awaiting reinforcements.
Siloed teams – There was no architect to provide cross-team direction.
Independent strategies – Because the teams were siloed, they were developing with different tech stacks and principles.
Offshore resources without proper support – There was not enough time to focus efforts on kickstarting the offshore team.
So with a fully maxed-out team, and company goals to automate a certain percentage of tests, the team began quickly falling behind.
Solutions Come From Unexpected Places
In my regular meetings with our director of development, we discussed the need to automate, and the obstacles we faced. Out of the blue one day, he approached me and said one of his teams had a spare developer that he could lend me for a couple of months.
Of course, I jumped!
In less than two weeks, the developer managed to:
Meet with the offshore automation engineers and remove their obstacles. (It just took some dedicated attention and a little bit of developer intuition.)
Review tests written by each team and establish a common strategy based on development principles.
Easily clean up stale tests that had begun failing due to lack of maintenance.
Work across product teams to establish an automation guild, to conform and advise on best practices across the company.
Bring a voice of experience to the table as the team was determining whether it should invest in certain tools.
We now have a Kanban board where all engineers can post their wish lists for anything from help setting up tools, technical expertise for tougher tests, and overall guidance.
An Added Bonus
Now that we are making solid progress on our automation goals, we are able to prove automation’s worth to the rest of the world. As we begin pulling our tests into the Continuous Integration process, we will increase the speed to release with a higher quality product.
Once we’ve established the worth of a dedicated resource with development skills, we might be able to leverage this into a new position for the QA team.
At a previous company, I worked on an automation effort where we had a group of developers dedicated to supporting our huge automation effort. The developers shared that they preferred working on the automation team over the development teams because:
They were constantly stimulated with new problems to solve.
There was always a new tool to explore.
They didn’t feel locked into working on long projects with a narrow focus of features to code.
I mentioned this to my developer, and sure enough, he is really enjoying this. He is in a position to guide teams, establish strategy, and generally feel like he is making a valuable contribution to the overall development effort.
“Mom, can I keep him?”
If he returns after his time working with us, I know I’ll have a strong ally on the development team going forward.
Moral of the Story
Sometimes answers are closer than you think. You should reach out to your development team. You might not be as lucky as I’ve been, but you may at least see interest from developers willing to reach out to lend a hand.
If that fails, consider bringing in a developer on a short-term contract. My experience has proven to me that it’s worth it.
Joe Nolan (@JoeSolobx) is a QA Team Manager with over 12 years of experience leading multi-nationally located mobile and web QA teams, and is the co-organizer of the DC Agile Software Testing Group (DCAST) Meetup.
