SDET vs QA engineer: what the titles actually mean

The distinction that survives across companies is about ownership. A QA engineer owns the quality judgment: what to test, what risk we're accepting, whether this release is safe. An SDET owns the test code and the systems that run it: the framework, the fixtures, the pipeline, the test data, the reporting. Both roles test. Only one of them is expected to be reviewed by developers as a peer on a pull request.

That's the line worth understanding, because it tells you what actually changes when you move. You are not being asked to stop being a tester and start being a developer. You are being asked to add a second thing you own, and to be judged on the quality of the code you write to do it.

The short version

A QA engineer is accountable for whether the product is good. An SDET is accountable for whether the product is good and for the engineering that proves it, at a scale no human could click through. An automation engineer usually sits in between: writes tests inside a framework someone else designed, rather than designing it.

The comparison

The row that matters most is reports into. When the SDET reports into engineering, everything else follows: the code review standard, the design involvement, and how the role is levelled relative to developers.

What each actually does on a Tuesday

QA engineer. Reads a ticket that says "user can update payment method." Notices it doesn't say what happens if the new card fails authorisation halfway through a subscription renewal. Asks in refinement. That question is the job. Then designs the cases, runs the ones that need a human, files two bugs with reproduction steps clear enough that nobody replies "works on my machine".

Automation engineer. Takes that same feature and writes the regression coverage. Adds a page object, adds six specs, spends an hour on the one that's flaky because the toast notification disappears before the assertion runs. Fixes it with a proper wait condition rather than a sleep, and moves on.

SDET. Gets asked why the suite takes 40 minutes and fails twice a week for reasons nobody trusts. Discovers the tests share a single seeded account, so parallel runs collide. Rebuilds test data so each worker gets its own tenant, shards the run across four machines, adds a quarantine tag for known-flaky specs so they stop blocking merges, and writes the report that shows flake rate dropping week over week.

Those are three different problems. The third one is an engineering problem that happens to be about tests.

SDET vs automation engineer

These two get conflated more than SDET and QA do, and the difference is easy to state: an automation engineer is a consumer of a framework, an SDET is a producer of one.

If you can write a Playwright spec but couldn't explain why your project uses fixtures instead of beforeEach hooks, how the reporter is wired, or what happens when a test fails on CI but passes locally, you are working at the automation engineer level. That is a real, valued level. It is also the level where the largest number of people are stuck, because writing more specs never automatically teaches you architecture. You have to go after that separately.

The practical test: could you start a new repo tomorrow and stand up a test framework that a team of six could work in for two years without hating you? Config per environment, auth handled once, parallel-safe data, sensible failure artefacts, CI integration, a defensible folder structure. If yes, you interview as an SDET regardless of your current title — the SDET question bank is the fastest way to check yourself against what those loops actually probe.

The overlap nobody mentions

Strong SDETs are usually excellent manual testers. Not occasionally — usually.

The reason is that automation only encodes decisions someone already made. If you can't tell which of forty possible checks on a checkout flow actually matter, you'll automate all forty, and now you have a slow suite that fails constantly and tests nothing important. Test design is upstream of test code. Someone who spent three years finding real bugs by hand has that instinct. Someone who went straight from a bootcamp to Selenium usually doesn't, and doesn't know they're missing it.

This is the part of your manual background that is an asset, and it is worth saying out loud in interviews. Not "I did manual testing for four years", which sounds like an apology. Instead: "I've seen how this flow breaks in production, so here's what I'd cover first and what I'd deliberately leave out of the automated suite."

Which one should you aim for?

Aim for SDET if you like systems, want your ceiling raised, and are willing to spend real time being bad at programming before you're good at it. The role has the longest runway, and it converts into platform engineering, developer experience and engineering management more easily than a QA track does.

Stay on the QA engineering track if the part you love is the product, the users and the risk call. That track goes QA engineer to QA lead to head of quality, and at senior levels it's a strategy job. It is a smaller job market with fewer entry points, and it rewards people who are excellent at it rather than merely competent.

The one thing that doesn't work in the current market is staying at "I execute test cases someone else wrote" and expecting the role to hold its value. That position is being squeezed from both directions — by automation below it and by AI-assisted test generation beside it. The longer version of that argument is in is manual testing dying?

How hiring managers actually read your CV

They look for three signals, roughly in this order:

1. Can you write code that survives review? A public repo with a small, clean framework beats "5 years automation experience" on a bullet list. They will skim your commits. The Code Lab is where you build that muscle without local setup.
2. Do you understand failure? Anyone can describe a passing test. Explaining a specific flaky test you diagnosed, what caused it, and what you changed separates real experience from course completion.
3. Do you make decisions or receive them? "We automated the regression suite" is a sentence about a team. "I argued we should not automate the PDF export checks because the rendering differences were cosmetic, and here's what we did instead" is a sentence about you.

None of those require permission from your current employer. You can build all three on your own time, which is the only realistic option when your job title says manual QA and your company has no automation to work on.