Software Development Engineer in Test (SDET) Job Description

A Software Development Engineer in Test (SDET) writes software whose purpose is to find out whether other software works. The output is code: test frameworks, fixtures, mocks, data builders, harnesses that start services in containers, and the pipeline stages that run all of it on every pull request. Where a manual tester works through a test plan, an SDET turns that plan into something a machine can run on every commit and that a feature developer can extend without filing a ticket.

The naming has never settled. Some teams call the role software engineer in test, and others fold the work into a general software engineer title. Other employers post similar work as test automation engineer, software test engineer or QA automation engineer, and O*NET files those titles under Software Quality Assurance Analysts and Testers (SOC 15-1253).

The work, layer by layer

Unit and component level. SDETs review how feature code is built so it can be tested: dependency injection instead of hard-wired clients, clocks and random seeds that a test can control, side effects pushed to the edges. They write or pair on unit tests in JUnit 5, pytest, Jest or Vitest, and they build the shared helpers that keep those tests short and readable.

Service and API level. In a distributed system the seams between services need their own tests. SDETs write API suites with REST Assured, pytest with httpx, or supertest, and set up consumer-driven contract tests with Pact so a team learns it broke a downstream caller before the merge instead of after the deploy.

Browser and mobile level. End-to-end suites drive a real browser through Playwright, Selenium WebDriver or Cypress, or a device through Appium, Espresso or XCUITest. A newer browser automation protocol is still a draft: WebDriver BiDi, the W3C specification for a bidirectional protocol to remotely control browsers, remained a W3C Working Draft as of November 2026.

Performance. Load scripts in k6, Gatling, JMeter or Locust check latency percentiles and error rates against a service's objectives before a launch or a traffic event.

Pipeline and signal quality. A test has value only if it runs on every change and developers believe its result. SDETs split suites into fast pre-merge and slower post-merge stages, shard them across runners in GitHub Actions, GitLab CI or Jenkins, quarantine flaky tests with an owner, and publish results through reporters such as Allure so a red build points at a failing assertion rather than at an environment hiccup.

Where judgment comes in

The hardest calls are about what not to test. Every end-to-end test costs runtime and upkeep; every gap risks an escaped defect. An SDET decides which risks get a unit test, which get a contract, which get a browser test and which are better caught by production monitoring, then writes that down as a test strategy the team can challenge. Good SDETs also say no: to a thousand-step UI suite nobody can maintain, and to a coverage target that rewards trivial assertions.

Education

As a rough guide, SDETs arrive with a bachelor's degree in computer science, software engineering or a related field, and the Occupational Outlook Handbook lists a bachelor's degree as the typical entry-level education for this occupation group. Bootcamp and self-taught candidates can compete when they bring evidence: a public test framework, merged pull requests in an open-source testing tool, or a CI pipeline they designed and can explain line by line.

Experience

People reach the role from three directions. Some start as feature developers who found they liked breaking things more than building them. Some come from manual QA and learned to code by automating their own regression checklists. Others join straight out of school into an entry-level SDET or test automation slot. As a rough guide, a mid-level SDET has about 3 to 5 years of hands-on automation work, including at least one framework or pipeline they owned rather than inherited.

Technical skills

• Languages: production-quality Java, Python, TypeScript or C#. Test code goes through the same review as feature code, so readability and design matter.
• Test frameworks: JUnit 5 or TestNG, pytest, Jest or Vitest for unit work; Playwright, Selenium WebDriver or Cypress for browsers; Appium, Espresso or XCUITest for mobile.
• Service testing: REST Assured, httpx, supertest, Pact for contracts, WireMock for service virtualization, and gRPC tooling where services use it.
• Environments: Docker, Testcontainers and short-lived Kubernetes namespaces for isolated test stacks.
• Pipelines: GitHub Actions, GitLab CI or Jenkins, including caching, parallel runners and test-impact selection.
• Data: SQL, data factories, and masking or synthesizing records so tests never depend on copied production data.
• Debugging: reading logs, traces and metrics, including OpenTelemetry traces, to separate a product defect from a test defect.

Certifications

No certification is required to hold the title. Candidates who want one tend to look at these:

• Certified Tester Foundation Level (CTFL), International Software Testing Qualifications Board (ISTQB)
• Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0, ISTQB
• Certified Software Quality Engineer (CSQE), ASQ

Cloud credentials from AWS, Microsoft or Google help when the job includes building test infrastructure on that provider.

What to be ready to show

Expect to write working code under time pressure, to design a test strategy for a feature you have never seen, and to talk through a flaky test you diagnosed: what the symptom was, how you reproduced it, and what you changed so it stayed fixed.

The federal picture

BLS does not publish projections for SDETs as such. Its Occupational Outlook Handbook groups software developers, quality assurance analysts and testers, and projects overall employment for the group to grow 10 percent from 2025 to 2035, which BLS calls much faster than the average for all occupations. BLS projects about 106,100 openings for the group each year on average. The Handbook ties that demand to continued expansion of software development for artificial intelligence, the internet of things, robotics and other automation applications, and to investment in software that protects networks and infrastructure in response to concerns over threats to computer security.

The narrower occupation that O*NET maps test automation titles to, Software Quality Assurance Analysts and Testers, had 186,740 jobs in the May 2025 wage survey.

Pay by industry

Industry rows from the same May 2025 survey show how setting changes the numbers for the occupation. At software publishers, the median was $101,070 and the 90th percentile was $169,730. In credit intermediation, the banking and lending industry group, the median was $106,500 and the 90th percentile was $158,060. These are figures for the whole occupation, testers and analysts included; BLS does not split out engineers who write automation code.

Regulation: medical device quality software

SDETs who test the software medical device makers use to run production and quality systems now work under a changed rulebook. FDA's Quality Management System Regulation, the amended 21 CFR 820, took effect on February 2, 2026. The next day, February 3, 2026, FDA issued a revised version of its final guidance "Computer Software Assurance for Production and Quality Management System Software," which supersedes the version issued September 24, 2025. The guidance describes computer software assurance as a risk-based approach to establish confidence in the automation used for production or quality management systems. For features, functions and operations that are not high process risk, it says manufacturers may consider unscripted testing methods such as scenario testing, error-guessing and exploratory testing. The document carries nonbinding recommendations, but it lays out FDA's recommended approach to matching test rigor to risk instead of scripting every check.

AI and generated tests

Some of the public data on LLM-written tests comes from employers measuring their own tools. Meta's TestGen-LLM, described in a February 2024 paper, uses LLMs to improve existing human-written tests and checks that each generated test class clears a set of filters that assure measurable improvement over the original suite. In an evaluation on Instagram's Reels and Stories products, 75% of its test cases built correctly, 57% passed reliably and 25% increased coverage. During Instagram and Facebook test-a-thons it improved 11.5% of the classes it was applied to, and Meta engineers accepted 73% of its recommendations for production deployment.

In that process, generated tests had to pass automatic filters and then engineer review. Someone has to write the filters, define what a passing test must prove, and review what the generator produces; those are test-engineering tasks.

Where the career goes

Paths branch toward senior and staff SDET roles that own test infrastructure across many teams, developer productivity or build engineering groups, quality engineering management, and lateral moves into feature development, site reliability or platform engineering. The skills transfer because the job was software engineering all along.

Dear Hiring Manager,

I am applying for the Software Development Engineer in Test opening on your payments platform team. For the past four years I have been an SDET at a regional bank's digital channel group, where I own the automation for our card-servicing APIs and the web app that sits on top of them.

When I joined, our regression suite was a set of browser scripts that took most of an afternoon to run and failed often enough that people stopped reading the results. I rebuilt it in three layers. Business rules moved into fast pytest suites against the service layer. The links between our six internal services got Pact contracts, verified in each provider's pipeline. The browser suite shrank to the dozen journeys that would page someone at night if they broke, rewritten in Playwright with stable selectors agreed with the front-end team.

The pull request check now finishes while a reviewer is still reading the diff, and the full suite runs after merge. I also set up a quarantine lane for flaky tests: any test that flips on unchanged code moves out of the blocking stage, gets an owner, and comes back only after a fix. Within a quarter the quarantine list was short enough that we reviewed it in standup.

The work I am proudest of is less visible. I pushed for an injectable clock in our billing code, which let us test statement cutoff dates without waiting for the calendar, and found two date-boundary bugs before customers did.

Your team's move to event-driven services is the kind of testing problem I want next. I would welcome a conversation about how you verify asynchronous flows today.

Sincerely, Jordan Alvarez