SDET
An SDET, short for Software Development Engineer in Test, is an engineer whose job is writing code that tests other code: automated suites, test frameworks, data generators and the pipeline plumbing that runs them. The title marks a developer who works on testing, as opposed to a tester who executes test cases by hand.
The longer version
The role sits between development and QA. An SDET writes production-grade code, reads application source to decide where a check belongs, and reviews other engineers' tests the way a developer reviews a pull request. Job descriptions tend to ask for programming skill first and testing knowledge second, which is the reverse of the ordering for a tester who works from written test cases and may never open the codebase.
What an SDET produces is mostly infrastructure other people use. That means a UI or API automation framework the rest of the team extends, builders for test data, contract tests between services, CI jobs that run suites in parallel, and dashboards that separate flaky tests from real failures. Part of the work is making a failure readable, because a red build nobody can interpret gets re-run until it turns green and then ignored.
Where an SDET sits varies by company. Some keep SDETs in a central team serving several products, some embed one in every feature team, and some have dropped the title and expect each developer to own the tests for their own code. A posting headed test automation engineer or quality engineer can describe identical work, so the listed responsibilities say more than the label does.
Common questions
What does SDET stand for?
SDET stands for Software Development Engineer in Test. The words put the emphasis on development: the person is an engineer who builds software, and the software they build is for testing.
What does an SDET do day to day?
An SDET writes and maintains automated tests and the framework around them, builds tooling such as data seeders and environment scripts, fixes flaky tests, and works with developers on how testable a feature is before it is built. Reading failures from the CI pipeline fills a large share of the week.
Is an SDET the same as a QA engineer?
Companies use both titles loosely, so the answer depends on the employer. Where the two are separated, the SDET is the one expected to write automation code and tooling, while the QA engineer may spend more time on test planning, manual testing and exploratory work. The responsibilities in the posting are a better guide than the title.
Do SDETs replace manual testers?
Automation covers repeatable checks, and an SDET builds that coverage, but exploratory testing, usability judgement and a first look at a new feature still need a person. Most teams that employ SDETs also keep people doing manual and exploratory testing.
What skills does an SDET need?
An SDET needs programming skill in the language of the product or its test tooling, fluency with a test framework, a working grasp of CI pipelines, and the testing fundamentals that decide what is worth automating. Reading someone else's code well matters as much as writing new code.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.