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.
Job Profile For an Automation Engineer in Testing Tasks:
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.
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
āDeveloping Testing Tools (not automated tests/checks)ā
I recently made picture about that:
Iām happy that Iām a āfull stackā tester who can develop.
I also love this.
Automation is only one part and I would never go for pure (test) automation job.
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.
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.
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.
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?
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.
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.
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.
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.
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.
Job Profile For an Automation Engineer in Testing Tasks: 
