SDET vs Automation Tester vs Manual QA
Three genuinely different jobs that are routinely advertised as seniority levels of one — what each actually does, and what goes wrong when the distinction is lost.
3 min read · updated 19 September 2026
Three job titles, routinely used as if they were seniority levels of one job. They are not, and the confusion causes real damage: teams hire an SDET and give them an automation tester's work, or drop manual QA on the grounds that "we have automation now" and discover what that was for.
#SDET
A software engineer whose product is testability.
What they build:
- Test harnesses and frameworks other people write tests in
- Fixtures, factories and test data tooling
- CI infrastructure: parallelism, sharding, reporting, artefacts
- Test environments and their provisioning
- Changes to the application that make it possible to test — seams, hooks, deterministic clocks, a way to arrange state without the UI
That last one is the distinguishing item. An SDET has commit access to the production codebase and uses it. They fix untestable code rather than working around it.
The measure of an SDET is not how many tests they wrote. It is whether everybody else's tests got easier to write and faster to run.
#Automation tester
An engineer who writes and maintains the tests themselves.
The skill is not "can write code" — that is assumed. It is:
- Knowing what is worth automating and what is not
- Expressing a test so it survives a refactor
- Choosing the right level for a risk
- Keeping a suite maintainable at three hundred tests rather than thirty
- Diagnosing a flaky test rather than retrying it
This is a different skill from building the machinery, and both are learnable by the same person. The confusion arises when an organisation hires for one and needs the other.
#Manual QA / exploratory testing
The only one of the three that can find a problem nobody thought to look for.
The name is unfortunate. "Manual" suggests doing by hand what could be automated, which is not the job. The job is investigation: forming hypotheses about how the system might fail and pursuing them.
Automation checks known expectations. It runs the assertions someone already wrote. It cannot notice that the error message is technically correct and completely unhelpful, that the flow makes no sense for a first-time user, or that a feature works perfectly and solves the wrong problem.
Automation Exploratory testing
──────────────────────────── ─────────────────────────────────
checks what you expected finds what you did not expect
scales to thousands of runs does not scale; does not need to
never gets bored notices when something feels wrong
regression discoveryA team with excellent automation and no exploratory testing ships confidently and is regularly astonished.
#The anti-patterns
"We automated everything, so we do not need QA." You automated the things you thought of. The incidents come from the rest.
"QA writes the tests." A separate team writing automation against an application they cannot change produces an ice cream cone — everything at the end-to-end level, because that is the only level they have access to. The shape is a symptom of the org chart, not of ignorance.
"Developers write all the tests, so we need nobody." Developers test what they built the way they built it. They are the worst possible people to find their own blind spots, and this is not a character flaw.
"SDET is the promotion from automation tester." They are different jobs. Some people want to build platforms; some want to break products. Forcing the second into the first loses both.
#What a healthy split looks like
| Who | |
|---|---|
| Unit tests | developers, always |
| Integration tests | developers |
| Component / API tests | developers, with SDET tooling |
| End-to-end journeys | automation testers, or developers |
| Test framework, fixtures, CI | SDET |
| Test environments and data | SDET |
| Exploratory testing | QA, plus everyone |
| Test strategy | whole team |
The load-bearing row is the first. When developers do not write unit tests, everything else is compensation — and the compensation happens at the most expensive level.
#Hiring order, for a small team
- Someone who tests exploratorily and can automate. A small team's developers can write unit tests; what they lack is someone who thinks adversarially about the product.
- An SDET, when test infrastructure becomes the bottleneck — the suite is slow, environments are a problem, data setup takes longer than the tests.
- Automation testers, when the surface is large enough that maintaining the suite is a full-time job.
Hiring in the reverse order is common and produces a large, slow, flaky end-to-end suite maintained by people who cannot change the application that makes it flaky.
Common questions
- Is an SDET just a tester who can code?
- No. An SDET is a software engineer whose product is testability — harnesses, fixtures, data tooling, CI infrastructure, and changes to the application itself. They write production code. An automation tester writes tests against the application as it is.
- Is manual QA obsolete?
- No, and the framing is the problem. Automation checks known expectations and cannot be surprised; exploratory testing finds the problems nobody thought to look for. A team with excellent automation and no exploratory testing ships confidently and is regularly astonished.
- Which role should a small team hire first?
- Usually someone with strong exploratory testing skills who can also automate, because a small team's developers can write unit tests but rarely think adversarially about their own work. The dedicated SDET role pays off later, when test infrastructure becomes a bottleneck.
Runnable samples for this page
last test results ↗- TypeScript
typescript/src/roles/sdet-vs-automation-tester-vs-manual-qa
Working tests, not fragments — they run in CI on every push to 8exgh/endtoendtester-samples.
Was this page useful?
Related topics
- Test StrategyDeciding what to test, at which level, and what not to test at all — written down, so it is a choice rather than an accident.
- Quality OwnershipWhen a defect reaches production, whose failure is it? The answers that feel good, the one that works, and the practices that make it real.
- Shift Left TestingMoving quality work earlier — into design, the pull request and the developer's inner loop — and the version of the idea that is just moving work without moving support.
- Writing Testable CodeThe properties that make code easy to test — pure cores, injected edges, no hidden state — and the specific smells that make it hard.
- The Testing PyramidWhy cheap tests must outnumber expensive ones, what the pyramid actually claims, the trophy and honeycomb alternatives, and how to tell which shape you really have.
- Behaviour-Driven DevelopmentBDD as a conversation practice rather than a tool choice — what the three amigos session produces, when Cucumber earns its place, and how it fails.
- Given-When-ThenThe Gherkin vocabulary for describing behaviour, how it maps onto arrange-act-assert, and when a shared specification language is worth its cost.
- Accessibility TestingWhat axe and similar tools genuinely catch, the roughly two-thirds they cannot, and how accessible markup makes your test suite more maintainable at the same time.