Welcome to another post about Automation Testing and the different labels we keep reading and hearing on job offers, articles and the internet in general. Today, and as a follow up to my previous article about differences in the Automation roles, I’ll talk about the Software Developer Engineer in Testing (SDET from now on) and the Automation Tester.
Imagine the confusion that these different tags on the technical tester cause: “Test Engineers”, “QA Engineers”, “Testers”., “Automation Testers”, “SDET”… A lot of people get really confused about what’s the title they have! 🤔
So, to put it clear from the beginning: They are not the same.
This was something that got more clear as soon as I moved overseas. On the global market, a Test Engineer is the person that knows how to write code in order to create test assets from scratch, without the need of using a tool to perform the tasks. They know and can use, for example, Selenium or Rest Assured, but they know how to create an automation test for the same thing creating customized test tools if necessary.
So, when we read about an Automation Tester, for me, is about the person that can automate tests using a set of tools, being them Selenium, TestProject (an awesome tool if you haven’t tried it yet!) or PyTest. There is nothing wrong with it neither! It’s a perfect scope and a valid specialization.
Usually, when someone starts their career in Automation, this is the first stage. It’s a range of tasks that is not super different from an actual manual tester, with the slight change that the tests are being executed with automated scripts, helped by tools provided externally.
SDET: You say we need to build a bike with Java to enable the Automation Testers to automate the tests? No problem!
The SDET is someone with deep programming knowledge and skills in more than 1 language. Generally, is a key part of the organizations as a member of a team supporting the different projects from a centralized point of view. Agnostic from the specifics, the SDET knows many options to solve every problem and also participates from the very start of the development phase.
The SDET will write the programs that will help Testing and, sometimes, the Automation Test Team as well. To give some examples I’ve worked in the past:
- Building Test Harnesses, with versioning and a SDLC on its own, for the Automation Teams to use to create their tests.
- Creating jobs in Jenkins running scripts that maintain a Confluence page with the full scope of all the domains of the company, their associated jobs, state of the executions, reports linked, etc.
- Deliver highly customized test assets with unorthodox mix of tools and techniques to preserve the privacy and confidentiality of a high profile client in Production environments to make sure the customer is having a good experience on specific actions on the application.
As you can see, the SDET is less involved in the pure breed testing activities, being behind the lines and playing a pivotal role that works as a bridge between a tester and a developer to help Manual and Automated Testing.
Generally, this position is for the more seasoned automation testers in the business. Sometimes this is filled by developers who ended up doing testing, but more frequently is a Tester who went through a long journey of development in parallel. This is the reason this position is on high demand: It’s a difficult set of skills and mindset what makes an SDET, something that doesn’t happen often. Let’s say that there are probably more pandas in the world than proper SDETs! 🐼😉
Conclusion
Even if it’s tempting to consider both roles as the same, I’ve found myself doing technical interviews to cover SDET positions in the team only to find that most Automation Testers consider themselves SDET as well, but lacking the skillset (and sometimes the mindset) when being challenged. Most of them were exposed only to Selenium, Cucumber and maybe Rest Assured, but never built a program to help Testing. And this, my friends, is where I feel we can find the difference.
Also, with all the great tools we see these days, like TestProject, the automation testing will be shifting more and more to the hands of functional testers, with the Automation Tester having to migrate into the SDET domain, to create and support these tools for the rest.
Where do you think you sit in this world of SDETs, Automation Testers and Functional Testers? Leave your comments! 👉