What does an Automation Engineer in Testing do?

Hi folks,

Iā€™m sharing a jobs profile for an Automation Engineer in Testing role.

The jobs profile below is a list of broad tasks that an Automation Engineer in Testing would complete as part of their job. We collated this list from over 100 surveys taken by Automators and Managers.

:automator:Job Profile For an Automation Engineer in Testing Tasks: :automator:

  • Creating The Automation Strategy
  • Building a Framework / Architecture
  • Creating Automated Tests
  • Setting up Test Environments
  • Setting up CI/CD pipeline
  • Investigate Failed Automated Tests
  • Reporting Automation Results
  • Maintaining Automated Tests
  • Maintaining Framework / Architecture
  • Maintaining Test Environments
  • Developing Testing Tools (not automated tests/checks)

This profile has been developed as part of the Automation Curriculum project where MoT aims to create a modern, open-source curriculum for those looking to get into Automation in Testing.

Iā€™d love to know what you think of this list. Is there anything missing? Is there any task that you think is beyond scope? Or maybe youā€™d like to share any common pitfalls or misconceptions youā€™ve encountered when completing any of these tasks.

All feedback is welcome. We want to build a comprehensive and relevant curriculum for the community. Let me know your thoughts.

8 Likes
  • Observing product code reviews
  • Participate in product design sessions
  • Training developers in the automation-test platform

re-wording of " Setting up CI/CD pipeline"

  • Setting up CI/CD pipeline for product build, test and reports
6 Likes

You could add everything a normal tester does, because by my experience the person will often work as such.
I see this represented by this existing 3 points from the list:

  • Investigate Failed Automated Tests
  • Reporting Automation Results
  • Maintaining Automated Tests

Iā€™m happy to see you added the last point :slight_smile:
ā€œDeveloping Testing Tools (not automated tests/checks)ā€
:+1:
I recently made picture about that:

4 Likes

That one is so brilliant, and the best part of this job.

3 Likes
  • Create test data (automated)
  • Test data management
  • Automate processes (not tests)
3 Likes
  • Create test data (automated)

Another way to phrase it:

  • Developing test data generators

:slight_smile:

3 Likes

Iā€™m happy that Iā€™m a ā€œfull stackā€ tester who can develop. :slight_smile:
I also love this.
Automation is only one part and I would never go for pure (test) automation job.

3 Likes

Greetings!

I personally cringe at the title of Automation Engineer preferring the broader Test Engineer. While most of your list is a part of what a Engineer does, I believe there is a very critical part that encourages collaboration and participates in design AND requirements sessions (much like @conrad.braam suggests). This role is also a conduit between Testers and Developers to facilitate a test approach that yields maximum coverage of risk-based scenarios at both a unit test and integration test levels. Assisting in test design and consulting on where automation may be beneficial is, in my opinion, also important.

I donā€™t believe that ā€œBuilding a Framework / Architectureā€ should be part of the profile. I have seen too many frameworks built only to have the framework steal time away from the Engineer for maintenance when they should be performing the more valuable parts of the role.
Indeed, your list includes maintenance and I agree there is a certain amount required. There are many third-party and community-supported frameworks that should be adopted for automation projects so the Engineer can focus on testing rather than developing. In that manner, the Engineer is maintaining tests (which is on the list) rather than frameworks.

Joe

6 Likes

And they harness the power of testing by creating a test harness :nerd_face:

3 Likes

Thanks for this Conrad.

  • Observing product code reviews

There will be many more curriculums to come, and as part of creating these we are also identifying ā€˜core skills/tasksā€™ that testers/quality folk should be doing. I view this as one of those, and will make a note to ensure itā€™s recorded. These core skills will then be woven throughout each of the curricula.

  • Participate in product design sessions

Same as above.

  • Training developers in the automation-test platform

This actually came up in the session we had and was later removed. It felt like a big leap for most of the industry. I agree its definitely something should happen, and I definitely see it returning in a future more advanced automation curricula. Built on top of this one. If that makes sense.

  • Setting up CI/CD pipeline for product build, test and reports

I like this rewording. It was inferred, but probably better to make it more explicit.

4 Likes

Absolutely.
Theyā€™ll be many more curricula to come and weā€™ll be covering all that.
We are also identifying core skills that will be woven throughout all the curricula, such as risk.

1 Like

Hey Joe,

Thanks for you comments.
In our research ā€˜Test Engineerā€™ still very much meant ā€˜manual testingā€™. These titles are likely going to get harder and harder, and donā€™t really matter too much. When finally published weā€™ll be added multiple alias to these curricula. And who knows, we may even change the name by the end of it.
Looking at job specs, most of the roles we saw had ā€˜automationā€™ in the titles somewhere.

Personally, Iā€™m viewing these more like hats a tester/quality focused worker could wear. As the future IMO, if folk will wear many hats.

Identifying whether to build your own, or use an existing 3rd party/OS/vendor would be covered in such a task. This could be changed to implementing, or some other word that satisifies that there needs to be one, whether we build it, or use an existing one. Any ideas on that wording?

3 Likes

Considering the following changes, thoughts?

Setting up CI/CD pipeline > Setting up CI/CD pipeline for tests and reports

We dropped the build, it feels like a potential rabbit hole, as that step can be very complex, and historically IME, done as a team. Doesnā€™t mean it canā€™t come up in a future curriculum, but I feel the majority add to an existing pipeline or solely focus on the tests/reporting.

Building a Framework / Architecture > Implement an Automation Framework

This change is to accommodate that fact you could chose to build you own depending on context or you could use an OS one, or even a vendor.

3 Likes

I like the idea of just covering what aliases test engineers use as a way of including people, and including ā€œdevelopers who testā€ as a intro point. But without going into debate about naming, we know names are important to people.

3 Likes

Hello @friendlytester and thanks for the reply!

I agree with your naming and hats ideas. The practice of Testing, in my opinion, is broadening and crossing into other disciplines that support product development.

I prefer your suggestion (Implementing). Itā€™s simple and clear enough to convey that some organization around the application of a program (aka automation) is required.
The creation and maintenance of an automation framework is, in my opinion, very much a programming task. Many people have the skill to create a framework however there is a subset of them that understand and appreciate how that design must accommodate testing. Indeed, I initially approached the role as a programmer attempting to satisfy a task.
As I grew in the role, I felt it automation was a tool in a toolbox that included more social skills than technical skills. The word ā€œengineerā€ in my title took on a larger meaning that included assessing testing opportunities across a project spectrum of requirements, design, implementation, and testing. The assessment informed the overall testing effort for the project.
I have been out of that role for two years but, as you might guess, I still bristle when I see developers with a title coming in to swing automation hammers that demonstrate technical prowess as opposed to a person with programming skills attempting to work with the Testing team to create tools that simplify the work. I much prefer the latter.

Thanks!
Joe

4 Likes

Agree, @devtotest test tools are for people to use. Very insightful there, building a tool that is social is super important. IMHO tools like selenium and appium (other less pretty tools do exist) are a complete trainsmash primarily, because they originally took the ā€œtechnical prowessā€ angle and thus today we have people using some tools as if they are hammers. Choosing or creating Frameworks is a very social thing, which I never thought about until you summed it up.

3 Likes

Thanks, let me elaborate on our choice as well.

Automation Engineer instead of Developer.
This is first thing Mark and I debated, we settled on Automation, as we feel the focus of this hat/role is to automate things, that enable rapid feedback loops. We wanted to avoid Developer, as we donā€™t want those hat/roles people getting pulled into feature work. I prefer the word toolsmith over all, but thatā€™s even less common. So we settled on Automation Engineer.

The reason weā€™ve dropped ā€˜Testā€™ and opted for ā€˜in Testingā€™ is I see far too many people focused on ā€˜testsā€™. They view the only way automation can be used is tests. Mark and I disagree with that and believe automation can be used to develop multiple tools that can be used to support testing.

So, the final idea is a hat/role focused on automating stuff/things that assist and support the testing efforts of the whole team.

4 Likes