What Is an SDET?

Ask “what is an SDET?” and most tech leaders will give you the short answer: a developer who writes automated tests. That answer is right, and it leaves out most of the story.

The role has roots at Microsoft in the 1990s, goes by several job titles depending on the company, and today covers far more than writing tests: test architecture, release pipelines, code review and, more and more, how AI-generated code gets checked before it goes live. If you’re deciding whether your team needs one, or how to hire for it, this is the full picture.

So, what is an SDET?

SDET stands for Software Development Engineer in Test: a developer whose main product is quality.

In practice, an SDET writes code that tests your software automatically on every change, builds and maintains the testing framework, connects it to your release pipeline, and works next to your developers from the first line of code (Testomat.io).

The simplest way to frame it: your developers own the features, and the SDET owns the system that proves those features still work after every change.

One role, many name tags

Even leaders who know the role well don’t always recognize it in a job post. Every company names it a little differently, and the titles overlap from team to team (Testomat.io). These are the versions you’ll see most:

• SDET (Software Development Engineer in Test): the original title. Microsoft pioneered it, Microsoft and Amazon made it popular, and today it shows up in job openings around the world (The Pragmatic Engineer; DEV Community).
• SET (Software Engineer in Test): Google’s version. Same idea, shorter name: Google dropped the “D,” and many companies followed (DEV Community).
• Developer in Test (DiT): common in teams where testing lives inside the dev team. Same daily work, with a title that leans developer (Testomat.io).
• Test Automation / QA Automation: all over job posts. Often writes automated tests inside a framework someone else built (Testomat.io).
• Quality Engineer, QA Engineer or Test Engineer: other titles companies use for similar work when they don’t have an SDET title (DEV Community).
• Engineering Productivity: the name of the Google organization where testing lives, built around making other developers more productive and more quality-minded (How Google Tests Software, via DEV Community).

So when you hire, skip the title debate and ask one question: does this person build the testing system, or only write tests inside one? A senior SDET does both, and that’s the difference you’ll feel by the second sprint.

The SDET origin story, in four scenes

1. Scene 1, 1979: a book flips the question. Glenford Myers publishes The Art of Software Testing with a bold idea for its time: you test software to find errors on purpose, not to prove it works. In his words, testing is “executing a program with the intent of finding errors” (AgileConnection). Every SDET still works with that mindset today.
2. Scene 2, the 1990s to 2004: Microsoft builds the role. Microsoft pioneered the SDET, most likely in the 1990s: a developer who wrote test code instead of product code, working on the same team as the developers. By 2004, its Exchange team was publicly explaining what the job meant (The Pragmatic Engineer). Google built its own version, the SET. And here’s a fun one: when Alberto Savoia joined Google as an engineering director in 2001, the company had about two hundred developers and three testers, according to his foreword to How Google Tests Software (DEV Community). Three.
3. Scene 3, 2004: Selenium and a chemistry joke. At ThoughtWorks in Chicago, Jason Huggins built a tool called “JavaScriptTestRunner” to test an internal time-and-expenses app (Selenium). Then a colleague joked that the new tool could “kill Mercury,” a rival testing product. Huggins went hunting for puns, found that selenium supplements are a cure for mercury poisoning, and replied: maybe we should name it Selenium. Everyone started calling it that right away. The best part? The rest of his email argued for a different name, “CheckEngine,” and everyone ignored it, as Huggins himself told the Selenium Users group. More than twenty years later, Selenium still holds roughly 22% of the QA automation market (Testomat.io).
4. Scene 4, 2026: AI writes the code, and someone still checks it. In a January 2026 SmartBear survey of 273 testing and quality decision-makers, 93% said their teams already use AI coding tools. At the same time, 68% were concerned that faster AI development will create testing bottlenecks (SmartBear). In other words, more code arrives faster than ever, and the person who designs how it all gets checked has never mattered more.

A week in the life of an SDET

At a senior level, an SDET rarely runs tests by hand. Most of their week goes into designing how testing works and reviewing the team’s code (Testomat.io). Here’s one way that week could look:

• Monday: builds the testing system. Picks the tools, sets the patterns, and keeps everything current as the product grows.
• Tuesday: writes automated tests at every level. From tiny checks on one function to full user journeys, like signing up or paying.
• Wednesday: wires testing into your release pipeline. As a result, every change gets checked on its own, and a failing check blocks the change from merging.
• Thursday: fixes the flaky tests. Tests that pass one day and fail the next get repaired or retired, so the team trusts every green check.
• Friday: reviews pull requests and reports on quality. The SDET spots code that will be hard to test, then shares pass rates and coverage gaps in a view the whole team can act on.

Of course, real weeks mix all of this together. The result stays the same, though: a team that releases often and knows exactly what’s going out the door.

Signs your team is ready for an SDET

If a few of these sound familiar, an SDET is probably the missing piece:

• You release an update, and the next day goes to fixing whatever it changed.
• Your customers are the ones telling you something isn’t working.
• Your developers spend more time on old bugs than on new features.
• Testing everything by hand takes days, so launch dates keep moving.
• Your team writes code with AI, and you want to be sure it all works before it goes live.
• There’s a part of your system the team prefers not to touch, because the last change there caused trouble.

Good news: none of these say anything about your developers’ talent. They simply show a team that has grown faster than the way it checks its work, and closing that gap is exactly what an SDET does best.

Why AI makes the SDET more valuable

AI agents can now draft tests from code changes, decide which tests to run first and explore an app looking for bugs. Great news, right? It is. However, someone still has to decide what’s worth testing, what “risky” means for your product, and which AI-generated tests deserve your trust (Testomat.io). That someone is the SDET.

Tools alone haven’t closed the gap either. In the same SmartBear survey, 87% of teams had automated at least a fifth of their testing, and 92% still tested manually (SmartBear). The tools are already on the shelf. What many teams are missing is the person who designs how they all work together, the same senior judgment we wrote about in AI coding agent oversight and the part of nearshore that stays human.

Our take: as AI writes more of the code, quality becomes a design decision, and a senior SDET is the professional who owns it.

Senior SDETs from Latin America, with Abstra

So, what is an SDET, in one line? The professional who lets your team build fast and trust every release.

At Abstra, we work with top-tier senior SDETs across Latin America, with exactly the profile this article describes. They join your team working your hours and fully dedicated to your product.

Thinking about adding one? Send us a message, and we’ll help you find the right person.

That’s Abstra.

FAQ

What is an SDET? An SDET is a developer who writes code that tests software automatically, builds the testing system around it, and connects it to the team’s release pipeline.

What does SDET stand for? Software Development Engineer in Test: a developer who writes code to test software automatically.

What’s the difference between an SDET and a QA tester? A QA tester checks the application, often by hand. An SDET writes the code and builds the system that checks it automatically, every time something changes.

Is an SDET the same as a test automation engineer? They overlap. A test automation engineer usually writes tests inside an existing framework; an SDET designs the framework and decides what gets tested where.

Does AI replace the SDET? No. AI speeds up writing tests, and the SDET decides what to test, defines what risk means for the product, and reviews what AI produces.