Who Should Be Doing Automation Work?
Testers sometimes look at automation work as the next career step after manual testing. Automation work has more visibility at the project level because the code lives on in a source code repository after someone thinks up the test idea, and it is seen daily as it runs in a continuous integration tool. People who do automation work usually also tend to have a little more social status.
Most of the time, though, I don’t think testers should be doing the automation work. I’ll share two experiences to explain why.
The first automation work I did was as part of a team working on UI automation. Each release cycle, the development team would work on a batch of features while a separate team of testers worked on those changes. After that release, the automation team got a new build and a set of tests to build.
We were separated from the feedback loop by a release, so any problems we discovered while building or running our tests were already in production. We were also separated in the communication loop by virtue of being on a different team and working in a different cadence. Without some serious research, all we knew about test coverage was the queue of tests we had built.
Most automation was done by a developer pair at another company. Developers would pull a change and build the code, using test-driven development as often as possible. The developers would write a test, then write the production code to make that test pass. This covered most of the unit tests.
The service tests were sometimes stubbed out before we built the code, or written after to see what a full response body looked like or how a workflow actually worked. Our UI tests, when new ones were needed or modifications were required, were usually built in a start-stop fashion. We would stub out a test and run it to the point where it failed. We would add to the UI test as we moved forward with implementing production code.
Automation built as part of the development process was done with a more holistic view of what was happening in the change. We knew what unit tests to make based on what we were building, what tests failed as result of our changes, and whatever coverage already existed. Problems we found by making these tests could be fixed right away, and by the people who found them.
We sometimes had testers involved in this process to help guide test design, or to explore the product, if we were at a good point to make a new container. We used automation as a tool for designing better code and as a way to inform future development.
There are plenty of technical skills testers can use in their daily work—continuous integration, the many aspects of browser tools, containers, data management—that don’t involve automating tests. In most cases, I think those are a much better and more efficient use of our time.
