Welcome back to another piece regarding Automation Testing and the various labels we keep seeing on job postings, articles, and the internet in general. Today, I'll discuss the Software Developer Engineer in Testing (SDET) and the Automation Tester, as a follow-up to my earlier essay about the differences in Automation roles.
Consider the confusion that these several labels on technical testers can cause: "Test Engineers," "QA Engineers," "Testers," "QA Automation Course," "SDET"... Many folks are perplexed as to what kind of title they have!
To be clear from the start, they are not the same thing.
As soon as I went to another country, this became more apparent. On the global market, a Test Engineer is someone who can develop code from scratch to produce test assets, rather than relying on a tool to complete the duties. They understand and can utilise Selenium or Rest Assured, for example, but they also know how to develop an automation test for the same thing, as well as create customised test tools if needed.
So, when we hear the term "automation tester," I think of someone who can automate tests using a set of tools such as Selenium, TestProject (a fantastic tool if you haven't used it yet! ), or PyTest. There's also nothing wrong with it! It's a great scope and a great specialty.
This is typically the first stage of a person's career in automation. It's a set of duties that aren't dissimilar to those performed by a manual tester, with the exception that the tests are run using automated scripts with the assistance of external tools.
SDET: So, in order for the software testing certified courses to automate the tests, we need to create a bike with Java? It's no problem! SDETs are programmers who are fluent in many languages and have extensive programming experience. In general, is an important aspect of the organisation as a member of a team that supports various projects from a centralised perspective. Although agnostic to particular, the SDET is well-versed in a variety of solutions to any problem and participates in the development process from the beginning.
The SDET will write programmes to assist Testing and, on occasion, the Automation Test Team. To offer you some samples of previous projects on which I've worked:
Building Test Harnesses for the Automation Teams to utilise to construct their tests, complete with versioning and an SDLC of their own. Creating Jenkins tasks that run scripts that maintain a Confluence page with the full scope of all the company's domains, their associated jobs, execution status, linked reports, and so on. Deliver highly tailored test assets using an unconventional mix of technologies and approaches in Production environments to ensure a high-profile client's privacy and secrecy while performing particular operations on the application. As you can see, the SDET is less involved in pure breed testing operations, preferring to work behind the scenes as a bridge between a tester and a developer to assist Manual and Automated Testing.
This role is often reserved for the company's more experienced automation testers. This is sometimes filled by developers who ended up doing testing, but it is most often filled by a Tester who went through a long development path concurrently. This is why this job is in such high demand: What constitutes an SDET is a difficult blend of abilities and mindset, something that doesn't happen very often. Let's just say there are definitely more pandas on this planet than SDETs!
Conclusion Even though it's tempting to lump both roles together, I've found myself conducting technical interviews to fill SDET positions only to discover that most Automation Testers consider themselves SDETs as well, but lack the talent (and occasionally the mentality) when faced with a difficulty. Most of them had only heard of Selenium, Cucumber, and possibly Rest Assured, but they had never created a tool to aid testing. And here, my friends, I believe we can make a difference.
Also, with all of the amazing tools available these days, such as TestProject, automation testing will increasingly fall into the hands of functional testers, forcing the Automation Tester to migrate into the SDET domain in order to design and support these tools for the rest.
Comments