I am constantly getting recruiting emails about being an automation engineer. What is an automation engineer to you?
A position that is often created around a lot of hype by people who don’t know much about testing.
Top response Tim. I couldn’t agree more
I usually find, especially with recruiters, that there is a lot of hype and misunderstanding around what an “automation engineer” is.
The reality is there is a very specific definition of “automation engineer”. It is someone who provides automated solutions to physical activities.
If I am going to test a web application then I would load the browser, navigate to the application website, interact with the website in accordance with the business requirements and features. An automation engineer would provide an automation solution to this physical activity. For example, I can use Selenium to load the browser, navigate to the application website and interact with the website.
In a similar note, there are people who over-engineer a solution. This holds true for all automation engineers. Not just for software automation engineers.
I’d have to disagree about there being a specific definition. I think its an amorphous term, just like with any job role (software engineer, support agent, admin etc) it means different things to different companies. Half the challenge of recruiting becomes finding someone who’s expectation of what it means is in line with what the company is looking for.
For example if recruiting for an ‘Automation Engineer’ do they want…
- Someone who can maintain an existing framework
- Someone who can build an entirely new framework
- Someone who can build an entirely new framework and perform the necessary platform config to get it plugged into a CI pipeline
Each of those would require different skill sets but will in my experience come under the same job title of ‘Automation Engineer’ or even just ‘Test Engineer’.
Personally I feel there should be a clear line between ‘Automation Engineer’ and ‘Test Automation Engineer’
In addition to @timm’s answer, I would say that these are positions created by people (or companies) who had problems with trying to even having basic automation support in their testing.
Good development skills don’t necessarily come together with good testing skills. Many companies have put their great testers to code and lost time in both developing it and on testing time.
It’s fairly understandable that they look for people who are good at developing automation code.
But it’s true, along it come a misunderstanding of what testing is - a misunderstanding that code can replace the human factor of it.