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.