On Your Software Team, Who Should Own Automation?
There is a prevalent question in the software world these days: Who should be working on automation—developers or testers?
One side of the argument claims developers should own automation. They need the feedback, have the agency to act on that feedback, and are close enough to the code to understand what needs to be automated. The other side says testers should own it because they have a deep understanding of test design.
I want to introduce something to this debate: nuance.
Most companies I have worked with have roles within the technical team. Some people write production code, and others focus on discovering ways that code might leave a customer unsatisfied. Sometimes there is a third role for people who turn very simple test ideas into code that runs against the product each time it is built. One job in particular stands out to me.
I started working at a small health care startup. We had five or six developers and a product person, and I was hired as the first tester. Developers wrote unit tests sometimes, but it wasn’t part of the standard coding practices at this company. We were trying to get our first customers, and getting code delivered was emphasized over building a test-driven development ivory tower of software. We had a couple of problems: Releases would occasionally have to be rolled back because of bugs, and developers weren’t willing to spend time on unit testing because it would cut significant time from feature development.
I attacked this problem as part of my role as a tester. First, I built a small smoke test using WebDriver that we would run during the release process. This initially helped us to discover a bad release, and to roll a build back, before the customers were exposed to a software problem. We used this every release and discovered problems resulting in a rollback to the previous build a few times. I also built a handful of API tests in important parts of the product that absolutely had to work.
In this company, everyone on the technical team owned and worked on automation. I built my automated tests, and developers built some unit tests here and there when they felt it was important. Everyone on the team consumed the results.
The people working on automation were the right people. Each of us focused on the areas where we were needed and had the skill set to approach them. This effort could have been structured differently, and we could have optimized, but this worked, and we were delivering software on time.
The question of who should be doing automation might be useful as a guiding light. But it’s more important to look at the structure of your technical team, what skill sets are available, and what the skill distribution is. This equation with be slightly different in each company, or even each team, and it’s what you should let dictate who “should” be working on automation.
