SDET sounds like a made-up job title designed to make LinkedIn look better, but the role is real and solves an annoying problem: quality cannot be the responsibility of a team that only shows up at the end.
SDET is not QA by another name
Traditional QA receives a finished feature and looks for ways to break it. An SDET gets involved earlier, writes code, and treats quality as part of the product. The difference is not the tool; it is the timing and the mindset.
Owning quality means caring about the architecture's testability, what is easy or impossible to verify, and the cost of each test. Finding bugs is a consequence, not the goal.
Strategy before automating everything
The most common mistake is automating everything in sight. Six months later, you have 800 slow E2E tests that nobody trusts and everyone ignores.
Strategy means deciding what is worth automating, at which level, and what to leave out. A test that nobody reads when it fails is worse than no test at all: it creates a false sense of security while adding maintenance costs.
The pyramid—and why most teams build it upside down
The test pyramid is simple: lots of unit tests, some integration tests, and very few E2E tests. Fast and cheap at the bottom, expensive and fragile at the top.
Most teams build an ice cream cone: a pile of fragile E2E tests and almost no unit tests. It looks good in a coverage report and becomes unbearable in practice—every deploy turns into a lottery. If your UI tests are the first line of defense, something went wrong much earlier.
Flaky tests are debt, not a minor detail
A flaky test is one that passes and fails without you changing anything. It seems harmless. It is not. It trains the team to ignore the red, and on the day something really breaks, nobody will look.
A hard rule: fix a flaky test or remove it from the suite. Leaving “just this one” in place is like leaving a broken window unrepaired—in no time, half the suite becomes noise and CI turns into decoration that everyone learns to ignore.
Automation without CI is theater
A test that only runs on your machine protects no one. Its value appears when it runs on every pull request and blocks the merge if it fails.
A fast, reliable suite in the pipeline changes the team's behavior: you can refactor without fear because CI provides immediate feedback. A slow, unstable suite does the opposite—everyone learns to skip it and click “merge” anyway.
When manual testing still wins
Automation does not eliminate manual testing; it changes its focus. Robots are great at repetition and terrible at judgment. Exploratory testing, usability, and that feeling that “something is off” even though nobody wrote it in the requirements—those are human territory.
A good SDET automates repetitive work to free up people's time for what requires thought. Manually testing the same flow for the thousandth time is not dedication; it is waste.
SDETs work WITH developers, not against them
An SDET who throws bugs over the wall and disappears becomes the team's enemy. The good version of the role does the opposite: it brings people closer. The SDET helps developers write tests, reviews testability in pull requests, and makes quality easy to build into the work.
When it works, the boundary between “the people who develop” and “the people who test” disappears. Everyone owns quality, and the SDET provides the tools that make this possible.
In the end, an SDET is not the person who presses the test button at the last minute. It is the person who enables the entire team to deliver quickly without breaking everything—and that is worth much more than any polished bug report.
