Clarifying the Role of Test Automation Engineer

Posted on October 17, 2016

The Role of Test Automation Engineer

Updated (6/26/17) – Clarified how much manual is “required” for test automation.

I’ve been made aware of assumptions I made in my last post about allocating automation engineers’ time. Please read that before reading this.

We all function on assumptions everyday at one level or another, but that doesn’t mean the ones I made shouldn’t be called out! Especially when it brings clarity where the message was clouded. I appreciate people doing it in such a respectful way.

First, I’ve become aware that the term “automation engineer” has either been overloaded or I’ve been using it differently than others. For others, “automation engineer” has the meaning “the role of taking pre-existing test cases and make the computer do them instead of people”. Maybe that’s what the meaning of the word is trending toward. I haven’t seen that meaning as the most popular. In fact, today was my first encounter with it, so I’m not ready to adjust my usage of the term at this point.

My meaning has always been “the role in which a person with sufficient technical know-how determines and implements how a feature should be wrapped with tests.” Also, it’s worth noting that some would use the work “check” in place of “test” here.

For a person in the role of automation engineer (as I’ve defined it) to succeed, certain things have to be in place. For automation engineers to do great work, they have to understand features, business needs, business processes, and customer priorities. So of course we have to be involved in feature definition! Further, we have to be involved with developers and other team members during construction and design in order to best test a system. Highly testable systems are that way because they are designed to be. So automation engineers must be involved in the activities of software construction and planning.

Manual Testing and Automation Engineers

Another assumption I made was that automation engineers must be manually testing and creating test cases as well as writing code to automate tests. In order to code the automation around a test case, you almost have to try it manually. To me, when the roles of test designer and automation engineer are divided (they don’t have to, by the way) there has to be a back-and-forth between people writing test cases and those implementing them in code. Just like there should be in writing application functionality… Who knows best how to implement a feature? The product owner or the software developer? Well, the software developer may know the code implementation the best, but the product owner knows what a feature must achieve. So it is with those who develop test cases and those who implement their automated counterparts. An automation engineer will have strong insight into how to develop a test case that a non-automation engineer will not.

Test Design and Automation

Also, it’s worth re-stating that I don’t believe the roles have to be split. I assumed in my first post that automation engineers would have some if not all control over designing test cases.

I don’t know that I’ve written even one UI test without attempting it manually. In doing so, a part of my process is to explore the application and the functionality for which I’m writing automated tests. When I write automated tests, I end up exploring the SUT with the automation I’m writing and I persist those test cases in the form of automated tests.

Further, I rarely find the most adequate method of testing a feature to be via the UI. When testing via the UI is not a good option, I have to design a test to interface with the system in another way. That is the most valuable work of test automation engineers. It is one that takes time, focus, patience, and most of all experience.

Circling Back Around…

The main point I was trying to get across in the previous post was that when managers set up automation engineers to spend a specific part of their time doing things unrelated to what they are attempting to automate, bad things happen.

Many thanks to Andrew Fowler, Richard Bradshaw and Gwen Diagram for pointing out my assumptions!