Articles
QA Engineer vs SDET: Testing Depth, Coding Expectations, and Career Fit
QA Engineer vs SDET: compare testing depth, coding expectations, and career fit using a payment example and practical questions to assess job descriptions.
QA Engineer vs SDET is best understood through what you own repeatedly. A QA Engineer role may center on understanding product risk and producing release evidence. A Software Development Engineer in Test (SDET) role may center on building the software and infrastructure that produce that evidence reliably. Both can involve coding, exploratory testing, debugging, and test strategy.
If you are choosing between job descriptions, the title alone cannot tell you how technical the work will be. This comparison uses official role examples and an original payment-testing exercise to help you assess testing depth, coding expectations, and career fit. It does not rank salaries or predict an employer's interview rounds.
QA Engineer vs SDET: the useful distinction
A QA Engineer helps evaluate software quality through activities such as requirements review, test design, exploration, automation, and defect investigation. The exact mix depends on the team. O*NET's official quality-assurance occupation includes test planning, problem documentation, and developing automated testing tools. O*NET occupational profile
An SDET applies software-development skills to testing systems: frameworks, fixtures, diagnostic tools, and integration with continuous integration (CI), which runs checks when code changes. Testing judgment remains essential because reliable execution of an irrelevant check provides little useful evidence.
The comparison below is our synthesis of responsibilities, not a standardized division of labor.
| Dimension | QA-centered responsibility | SDET-centered responsibility |
|---|---|---|
| Main output | Risk assessment and evidence about a feature | Maintainable software that generates evidence |
| Testing depth | Requirements, user behavior, boundaries, failure impact | Testability, controlled failures, isolation, diagnostics |
| Coding | May range from queries and scripts to substantial automation | Often central to frameworks, tools, and test infrastructure |
| Collaboration | Clarify acceptance criteria and communicate release risk | Improve interfaces and tools with development teams |
Neither column defines a ceiling. A senior QA Engineer may architect automation; an SDET may lead exploratory testing. Compare responsibilities at similar levels before treating the titles as different career ranks.
Official job descriptions show substantial overlap
Amazon's Quality Assurance Engineer 1, QRE posting explicitly combines test strategy, manual and automated testing, troubleshooting, and proficiency in a language such as Java, Python, or C#. This is direct evidence that a QA title does not imply a coding-free job. Amazon QRE role
Its Software Development Engineer-Test, Alexa Devices posting emphasizes building frameworks and tools, programming, and diagnosing software issues. It also includes manual testing and product-focused strategy. An SDET title therefore does not remove the need to examine behavior and understand customers. Amazon Alexa Devices role
For another employer example, Dutch's SDET posting names framework architecture, test-data management, CI integration, and testability agreements with developers. It specifically distinguishes framework coding from writing individual scripts. These postings illustrate possible responsibilities; they are not a representative survey or proof of a universal hiring standard. Dutch SDET role
Testing depth: examine one payment from two perspectives
Consider an original teaching scenario: a customer submits a payment, the service accepts it, but the response is lost. The customer retries. The requirement says that retrying the same logical request must not create another payment.
An idempotency key identifies a logical request so repeated attempts can reuse its recorded result. The provider's exact contract matters. Stripe, for example, documents retaining the first executed request's status and body for a key, including error results, and checking for conflicting parameters. That behavior should inform a Stripe integration's tests; it is not a specification for every payment system. Stripe idempotent requests
A QA-centered investigation begins by resolving ambiguity. What should the customer see while the outcome is uncertain? Which record proves that money moved? What happens if a retry changes the amount? Is another browser tab still using the same checkout? A green success banner alone cannot establish that the customer was charged correctly.
| Payment situation | Risk to investigate | Evidence to request |
|---|---|---|
| Response lost after acceptance | Customer retries and pays twice | Payment record and replayed result |
| Same key, changed amount | A different purchase is treated as the old one | Defined rejection and unchanged payment |
| Event delivered twice | Fulfillment runs twice | Event identity and fulfillment record |
| Confirmation arrives late | UI encourages another purchase | Pending state and recovery behavior |
The event case is separate from request retries. Stripe documents that webhook events can arrive more than once and that delivery order is not guaranteed. A request-level idempotency check does not establish correct event handling. Stripe webhook guidance
This is testing depth: identifying the observation needed to distinguish a safe outcome from an apparently successful one. It requires domain reasoning whether the checks are performed interactively or automated.
Coding depth: turn the requirement into an inspectable check
An SDET-centered deliverable makes the important case repeatable. A test harness supplies controlled inputs and dependencies, then records the results. Its design should let another engineer understand what happened without reproducing the entire investigation manually.
Here is a small Python check for the sequential replay requirement. pay is the system-under-test interface; records exposes the fixture's payment records. The same check can run against different implementations of that interface.
def check_replay(pay, records):
first = pay("attempt-1", 2500)
retry = pay("attempt-1", 2500)
assert retry["id"] == first["id"]
assert len(records) == 1
assert records[0]["amount_cents"] == 2500
The original local fixture uses an in-memory payment model with integer cents. We ran this check against the model and deliberately broken versions: one that creates a second payment, one that changes the replayed ID, and one that records the wrong amount. The assertions catch those faults. That establishes what this small check detects, not production payment correctness.
It does not simulate a lost network response, two concurrent workers, a process restart, or webhook delivery. A stronger harness would inject the lost response after acceptance, preserve the request key, and inspect durable records. Concurrent requests require a separate test of the service and storage boundary.
The engineering work is in making those conditions controllable, isolating each test's data, and preserving diagnostics. Playwright's official guidance similarly recommends independent tests with isolated state to improve reproducibility. Playwright best practices
A QA Engineer may implement this harness too. The career distinction is whether building and maintaining such infrastructure is a central responsibility, an occasional contribution, or handled by another team.
How much coding should you prepare?
Use three practical levels to assess a posting. These are preparation categories, not employer grades or promotion criteria.
Read and investigate: trace a request, understand a failing assertion, query relevant records, and explain error handling. Someone who relies on tools still needs to judge whether the evidence supports the conclusion.
Implement checks: write readable test functions, create fixtures, parse responses, handle failures, and keep tests independent. Be able to explain why an assertion detects the intended defect. Copying a browser script without understanding its data dependencies is weak evidence of this level.
Own test software: design reusable interfaces, review code, manage dependencies, integrate execution into CI, and debug failures across environments. Decide what belongs in a common library and what should remain explicit in a test. SDET postings centered on framework ownership warrant preparation at this level.
Ask about coding exercises, permitted languages, and framework-design expectations directly. General algorithm practice may help a specified coding round, but it cannot replace test design or debugging. Conversely, knowing a testing tool's commands does not establish software-design ability.
Read the job description through its expected outputs
Start with the verbs and objects. “Execute regression tests” describes different ownership from “design the regression framework,” even if both advertisements list Selenium. “Own quality” is too broad until the team explains the decisions and deliverables behind it.
For each attractive posting, write down the recurring output, code ownership, product involvement, and maintenance responsibility. Then use these questions in the recruiter or hiring-manager conversation:
- What would I deliver during a normal sprint: test evidence, framework changes, product code, or a combination?
- Who reviews the automation code and maintains the shared test infrastructure?
- How much access do I have to logs, source code, environments, and test data?
- When a test is unstable, who investigates it and decides what happens to the release?
- What distinguishes strong performance at this level from the next level?
Interpret answers together. A role promising framework ownership but offering no code-review support or time for maintenance needs clarification. A QA role with strong engineering access and substantial automation responsibility may fit a coding-oriented candidate better than an SDET role dominated by repetitive execution.
The point is to verify the work you would actually do. Tool lists and titles are useful search filters, but they are incomplete descriptions of the job.
Which role fits the work you want to repeat?
Prefer a QA-centered opportunity when you enjoy clarifying ambiguous behavior, exploring user journeys, comparing risks, and explaining release trade-offs. Check whether the team supports that judgment with access to engineering evidence. “QA” should not be interpreted as permission to stop learning technical skills.
Prefer an SDET-centered opportunity when you enjoy building reusable tools, diagnosing infrastructure problems, and maintaining code that other engineers depend on. The less glamorous work matters: upgrading dependencies, fixing fixture cleanup, and investigating why a failure appears only in CI.
If both appeal, look for a hybrid role with explicit priorities. Ask what happens when a release needs exploratory testing at the same time the framework needs repair. The answer reveals how the team allocates work and whether the advertised ownership is realistic.
If you are moving from manual-heavy QA toward SDET work, keep your risk judgment and add demonstrable code ownership. Build one small suite with isolated data, understandable failures, and a documented limitation. You do not need to pretend that QA experience was software-development ownership; show the additional skill directly.
Practice the responsibility you need to demonstrate
| Question | Evidence to produce |
|---|---|
| Plan QA testing for a new feature | A prioritized strategy with explicit unknowns |
| Contrast UI vs backend testing; design UI-change test cases | A justified choice of test boundaries |
| Reduce False Failures and Classify QA Outcomes | A diagnosis that separates product and test faults |
| Implement paginated API ingestion | Maintainable code with controlled failure handling |
| How do you conduct a code review exercise? | Actionable review comments tied to correctness |
Use the payment example as a small portfolio exercise. First write a risk note explaining the expected outcome and missing evidence. Then implement one repeatable check and deliberately introduce a defect it should detect. Finally, explain what remains untested and which boundary you would investigate next.
For QA Engineer vs SDET, choose the role whose recurring responsibilities you want to own and can substantiate.
Sources and Further Reading
- O*NET: Software Quality Assurance Analysts and Testers
- Amazon: Quality Assurance Engineer 1, QRE
- Amazon: Software Development Engineer-Test, Alexa Devices
- Dutch: SDET responsibilities and qualifications
- Stripe: Idempotent requests
- Stripe: Webhook delivery behavior
- Playwright: Best practices
Research checked September 19, 2026. Employer examples describe the cited postings; responsibilities and vacancies can change.