A few weeks ago I had some interesting debates on the projects I work on: Is the Automation Engineer a Developer? Is a Developer the best candidate to be an Automation Engineer? Where does the good ol’ Software Engineer in Test (SET, a.k.a SDET) fit in this fierce new world full of code and dependencies? 😵
It seems that the trend nowadays when looking for job candidates in Automation is that they need to have the skills of a programmer. I have been doing technical interviews for people who are running for Test Engineer positions for years, and this trend has been increasing more and more. That is why I give the same advice to anyone asking me how to get into the Automation World: “Start learning the fundamental concepts of object-oriented programming and how they apply to Automation Testing”.
So, Is the Test Engineer a Developer?
From my personal point of view the answer is: No, he/she is not a developer.
Do you have the skills of one? Yes, you share several of them, of course! But there is something fundamentally different and many do NOT seem to understand it. The mindset is different.
What do I mean by “The mindset”? Well, both the Automation engineer and the developer have two very different objectives. The developer seeks to create something that works according to the requirements. The Automation Engineer simply seeks to automate the repetitive and tedious tasks of the manual tester so that they are performed, without assistance, by a program. This is a very important difference one must comprehend. Let me explain with some examples I have personally seen over the years.
Developer Wannabes
Some time ago I fell into a project where the team had been automating for a while. They called me because over time, what they created had become a beast impossible to maintain.😲 The reason? The over-complication of the framework and the null standardization of what to do for each case. Some had used Gradle, others Maven, some Groovy, others simply Java…
The unnecessary complexity of the code had led to unthinkable things to cover a simple login to a portal. New joiners had problems with even getting the project to work due to how the dependencies were handled with spring and the null explanation of the code, which was so abstracted that, to find the entire behavior of a line of code, it was necessary to do a treasure hunt in layers upon layers of syntax.
The Automation Engineers had moved to the dark side… They had lost sight of the objective of their work: Making testing easier. They had focused so much on running their code, that between patching, wiring things to get them to work at any cost, and other not so cool decisions, they ended up with another project with defects. Another project that, after all, needed testing.
Are you familiar with the concept of Technical Debt? Well, here the Technical Debt was in red and they needed help! 🆘
To sum up a bit of the work I’ve done there – My sanitation was to create a testing framework according to the needs of the project, easy to understand for the new automation testers and robust enough so that it will not be hell to maintain. The criteria were given thanks to understanding the need of the testing team and also having the necessary development skills: They used Jenkins with pipelines made in Groovy, so Gradle and Groovy were chosen to build the test artifacts, manage dependencies and making everything work seamlessly. Selenium Webdriver joined the mix, with a solid base page that abstracted logic for simple actions on pages. Rest Assured was used separately in another project to handle the testing of the APIs provided by devs friends and presto. Everyone was happy! 🙌
There are various powerful open source and free automation platforms that can simplify automation even further and reduce the initial setup time. I would highly recommend checking out such solutions as well.
It’s important for me to mention that I do not mean that it is wrong for a developer to automate, or that a tester should not know anything about programming to automate. On the contrary: The developer who wants to automate should familiarize himself with the concepts of testing, as well as the tester must familiarize himself with the concepts of programming. It’s just that each should also be aware of their objectives. Nonetheless, my focus will always be to use developer skills and relate them directly with their application to create Automation frameworks.