Demystifying the SDET Unicorn

You Need an SDET Unicorn: Automation Engineers and Automated UI Tests Won’t Save You.

I have a potentially controversial opinion about my job. The popular concept of the Software Development Engineer in Test (SDET) role is broken by modern development practices.

I don’t say that lightly. After thirteen years in the industry and eight of those years focused on automation, I’ve lived through the shift to agile practices.

At best, rather than empower an agile team that may also be striving for a DevOps culture, SDETs are often just another silo that contributes to quality (ensuring correctness and completeness of the application) only for regression testing. At worst, they slow the entire development process down for no measurable benefit.

Imagine the mindset of a company. Picture finally moving to automation and the promises it brings, only to realize a year later that your SDET was just a three-day-long gate to the manual testers who did the same thing regardless of the SDET’s work.

Let’s say your team can’t keep up doing everything manually (a potentially regular occurrence for some), so you want to hire an SDET to help. What are the qualities of a modern, successful SDET?

Key Attributes of an Exemplary SDET

From a high level, I’ve observed a few attributes in successful SDETs:

1. They effectively grasp the quality needs of a broad range of stakeholders (developers, testers, business analysts, and even the customers*.) If not, they miss opportunities for quality improvement.
2. They coach others on quality software attributes to affect multiple steps of the software development lifecycle. This is the only way they keep up with modern development demands.
3. They effectively communicate the benefits of their work. Otherwise, they risk perception as a “typecast” employee, nothing more than a “code monkey” who uncritically writes automated UI tests to fulfill someone else’s asks instead of the organization’s needs.*This has a huge caveat. I try to live my professional life by the adage, “if it can be done, it will be done.” It gets exponentially more challenging to analyze plausible customer interactions with a complex system and then distill that into 100% effective test cases. I often expect to fail with my first test suite. Also, I expect to refine it to understand better how the customer uses the system (either through reports from production or via exploratory testing by manual testers.)

Mike Curn exemplifies the key attributes of a successful SDET in his work-from-home office.

Finding an SDET Unicorn

Long story short, the concept of an SDET should be quality-focused with technical ability. “Quality” is not achieved solely through manual or automated UI (User Interface) tests. Rather, “quality” is achieved by understanding testing software at many layers of an application.

This person might exist as somewhat of a unicorn:

“As well as participating in typical QA activities, they can write anything from automated integration tests, API tests, and/or UI automation tests.

In addition, SDETs could help review unit tests which are written by the developers…

Let’s be clear, an SDET is NOT an automation engineer.

Having the right balance of testing aptitude and technical skills is the key thing.

A great SDET is a software tester by trade, is passionate about software quality and at the same time is tech-savvy and has the right mix of technical skills.”

Amir Ghahrai – SDET Unicorns – Why is it so Hard to Hire SDETs?

Finding this “unicorn” is the challenge I see most frequently. Many in SDET positions either have the technical chops but not the testing mindset or the testing attitude but not the technical skill. To clarify, writing automated tests targeted at different layers of an application is not easy and is highly deliberate.

The SDET Origin Story

As the saying goes, “a defensive developer checks both ways before crossing a one-way street.”

Therefore, an SDET must help programmers check both ways before “crossing the street.” Afterward, verifying that it was the right destination when they get to the other side.

This is not a new concept. Microsoft has already had teams eliminate separate Dev and Test disciplines.

This separation of disciplines is partly because of these challenges:

“… full testing would take the better part of a day to run, many more hours to ‘analyze the results’ to identify false failures, and days or weeks to repair all the tests that were broken due to some legitimate change in the product.

So,  two years ago, we started on a path to completely redo testing.  We combined the dev and test orgs into a consolidating “engineering” org.  For the most part, we eliminated the distinction between people who code and people who test.  That’s not to say every person does an identical amount of each, but every person does some of everything and is accountable for the quality of what they produce.”

Brian Harry – How we approach testing VSTS to enable continuous delivery

Say what you want about Microsoft’s quality.

After using TFS and VSTS (now Azure DevOps), I have not in recent memory seen a critical failure in that software due to their code. However, Microsoft still has some semblance of a test feedback loop via their preview releases, Insider program, and issues and feedback on their various channels like GitHub issues and Microsoft Q&A.

Note: according to the Dev community, Microsoft originated the acronym “SDET.”

Mastering the SDET Role

I am not advocating against any acceptance testing. Instead, I’m arguing that a successful SDET must empower quality at almost every step in the software development process. Testing should be continuous.

A quality specialist should be knowledgeable about many of the steps Ashby mentions. Maybe not all, but they need to have a grasp that quality permeates everything. More importantly, because “everything” is too much for one person to handle, an SDET needs to suggest, question, coach, and implement so that the whole team benefits at every step of software development.

Want More?

What are some other qualities you’ve seen in a successful SDET unicorn? Chime in, and we can build a list for finding new people for our teams!

Also, check out Demystifying the Requirements-Gathering Environment for more insight into improving your software lifecycle experience!