logo logo

The Software Engineer in Test and the Developer: Key Differences

main post image

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.

Avatar

About the author

The Free Range Tester

I’m a consultant in all things Automation in Testing related. Originally from Argentina and currently working in the beautiful country of New Zealand, I’m passionate about learning new tools, testing the trends in the world of Automation and take the best practices to the next level, making my journey full of discoveries, experiments and, most importantly, fun!

I’ve vast knowledge and experience in both C# and Java and Selenium, Cucumber, Specflow and Rest Assured as the main tools among others. With the last months working on Python to support some Machine Learning and AI projects I’m working on as a hobby and also JS to test some of the trends in the Automation world, I try to keep myself learning as much as I can!

Currently teaching others how to automate from scratch, both virtually to Latin America and locally in New Zealand.

I’m also a Game Programmer and Guitar player on my free time!

Join TestProject Community

Get full access to the world's first cloud-based, open source friendly testing community. Enjoy TestProject's end-to-end test automation Platform, Forum, Blog and Docs - All for FREE.

Join Us Now  

Comments

11 1 comment

Leave a Reply

popup image

Best In Class Java and C# SDK

Join thousands of automation developers using TestProject to supercharge open source testing, with a Selenium and Appium SDK, supporting Java and .NET Core (C#)!
Sign Up Now right arrow
FacebookLinkedInTwitterEmail