The same "SDET" title can describe someone clicking through a web app manually and someone designing infrastructure for a test platform used by 200 engineers, because the industry never standardized which job each title refers to. Filtering your job search by title wastes months on the wrong roles. This article covers what each of the three titles actually signals in 2026 job postings, the real skill differences between them, and how to read requirements instead of titles when evaluating whether a position matches your background.
Why QA job titles are completely broken
Most industries have job titles that mean roughly the same thing across companies. A staff accountant does staff accounting work. A civil engineer designs civil engineering things. In QA, the same title can describe two jobs that share almost no day-to-day overlap.
The chaos comes from a few sources. Testing as a discipline evolved fast: from dedicated manual testers in the 1990s, to automation-focused roles in the 2000s, to engineering-heavy positions today. The titles never standardized across the industry. Companies also copy-paste titles from job boards without thinking about what they mean. Someone in HR sees "QA Automation Engineer" on a competitor's posting and reposts the same title even if the actual work is 90% manual. Automation skill requirements have also shifted dramatically in a short time, and the market hasn't caught up with the vocabulary.
The result: "QA Engineer," "Software QA Engineer," "QA Automation Engineer," "SDET," and "Software Development Engineer in Test" can describe anything from clicking through a web app manually to designing infrastructure for a test platform used by 200 engineers.
This means you cannot use the title to understand the job. You have to read the actual requirements. More on that later.
What "QA Engineer" actually means today
Historically, QA Engineer meant manual testing. Exploratory testing, writing test cases in spreadsheets or Jira, tracking bugs, maybe coordinating release sign-offs. No code required.
That definition is mostly obsolete, but the title lives on and today it can mean a wide range of things. In practice, when a company posts a "QA Engineer" role in 2026, they usually want someone who does manual testing as the primary work with some automation on the side. "Some automation" might mean running someone else's Playwright tests, writing a few scripts in an existing framework, or maintaining Postman collections for API smoke tests.
Picture this scenario: a 40-person startup has a product team shipping features every two weeks. They post for a "QA Engineer." What they actually need is someone to work closely with developers and product managers, catch issues before features ship, write test cases that document expected behavior, and own the quality conversation during sprint planning. If that person can also write a few automated smoke tests, great. But the role is fundamentally about product quality judgment, not engineering output.
That's the QA Engineer sweet spot in most non-tech-company hiring: someone who understands the product deeply, communicates defects clearly, and has enough automation exposure to not be slowed down by it.
Salary range for QA Engineers in this traditional sense is the lowest of the three titles discussed here. The gap reflects the technical demand differential, not a value judgment about the work.
What SDET means and where it came from
SDET stands for Software Development Engineer in Test. Microsoft created this title in the early 2000s and the definition was precise: an SDET writes production-quality code that tests software, evaluated on the same engineering standards as software developers.
At Microsoft, SDETs were full engineers who happened to focus on testability and quality infrastructure rather than product features. They designed test frameworks, wrote tools the rest of the QA organization used, reviewed production code for testability, and were expected to own entire subsystems of the test platform. A senior SDET might spend six months building a distributed test execution system that reduced CI runtime from two hours to fifteen minutes, writing no product tests themselves at all.
That engineering-first definition spread, but it got diluted. Today "SDET" is used inconsistently. At companies like Amazon, Google, or Meta, SDET still means what Microsoft intended: serious software engineering applied to quality. The coding bar is close to a software engineer bar. At smaller companies, "SDET" sometimes just means "we want more engineering rigor than a QA Engineer title implies."
A clean example of real SDET work: a company running 8,000 end-to-end tests notices their CI pipeline takes 90 minutes. An SDET is tasked with solving this. They analyze test distribution, build a sharding system that parallelizes test execution across 20 containers, write infrastructure-as-code to provision them dynamically, and add observability tooling so flaky tests are detected and quarantined automatically. At the end of this project, total CI time is 12 minutes. The SDET probably wrote 500 lines of product test code this quarter and 3,000 lines of framework and infrastructure code.
That's not QA work. That's software engineering work that makes QA work possible.
SDET roles at companies that apply the title rigorously pay significantly more than QA Engineer roles: typically 20–35% more for equivalent seniority levels, depending on company and region. At big tech companies specifically, SDETs are often on the same compensation band as software engineers.
What QA Automation Engineer means
This is the middle position, and it's the most common title you'll see in 2026.
A QA Automation Engineer writes automated tests and maintains the framework those tests run in. They're more code-focused than a traditional QA Engineer (automation isn't a side task, it's the primary job) but they're not building test infrastructure from scratch the way a true SDET does. They work within an existing framework, extending it and writing the actual test coverage.
In practice: a team is using Playwright with TypeScript, has a Page Object Model structure in place, and runs tests in GitHub Actions. A QA Automation Engineer joins and spends 70–80% of their time writing new tests for features as they ship, updating existing tests when the UI changes, investigating flaky tests, and improving test reliability. They might add a helper utility to the framework, improve error reporting, or set up a new test suite for a new part of the product. Redesigning the framework architecture is SDET territory.
The scenario looks like this: a developer ships a new checkout flow. The QA Automation Engineer reads the acceptance criteria, writes six Playwright tests covering the happy path and key edge cases, runs them locally against the staging environment, catches two edge cases that weren't handled, files bugs, and merges the tests to main once the bugs are fixed. A routine two-day piece of work. No framework design, no infrastructure work. Just solid, well-structured automated test coverage for a real feature.
That's the QA Automation Engineer job. It requires real coding ability: write clean, readable test code in a real language, understand async patterns, work comfortably with version control, and debug failures without developer handholding. It does not require a software engineering background.
Salary sits between QA Engineer and SDET. Companies hiring QA Automation Engineers are usually willing to pay notably more than for traditional QA because they need code output, but they're not running a full engineering interview loop.
How to figure out what a posting actually wants
Ignore the title entirely. Go straight to the requirements section and look for three signals.
Signal 1: What coding language and framework do they mention? If they say "experience with Playwright, Selenium, or Cypress," they want test automation. If they specify "strong programming skills in Python or Java" and then list framework-building or "test infrastructure" work, you're looking at SDET territory. If the requirements mention Jira, TestRail, or "test case documentation" but coding is optional or secondary, that's a manual-leaning QA role. Signal 2: What does the day-to-day work involve? "You will write automated tests for new features" is QA Automation Engineer work. "You will design and maintain our test automation framework" skews toward SDET. "You will coordinate testing across releases and manage the defect lifecycle" is traditional QA Engineer. Signal 3: Who do they say you'll work with? Working closely with "product managers and developers" signals product-quality focus (QA Engineer). Working with "the platform team to improve CI reliability" or "infrastructure engineers" signals SDET-type work.Here's a real example contrast. Posting A says: "3+ years of automation experience, Playwright or Selenium required, strong TypeScript skills, experience writing E2E test suites." That's a QA Automation Engineer role regardless of what the title says.
Posting B says: "Strong coding skills required, experience building test frameworks, knowledge of distributed systems a plus, design test infrastructure to support hundreds of engineers." That's an SDET role even if the title says "QA Engineer."
Also read the "nice to have" section. If they list Docker, Kubernetes, CI platform administration, or test observability tooling as bonuses, the company is thinking in SDET terms even if the title doesn't say so.
Which path to target based on your background
If you're coming from a completely non-technical background (support, project management, business analysis) start with the QA Engineer path. Build testing fundamentals, get comfortable with Jira and defect tracking, and add basic automation skills over time. The QA Engineer role is the most accessible entry point because companies care more about product thinking and communication than code output.
If you have some coding background (web development bootcamp, scripting experience, IT work) go straight for QA Automation Engineer. You already have the mental model for writing code; what you need is test-specific knowledge layered on top: how test suites are structured, Playwright, CI integration. This is the fastest path to a well-paying QA role for most career changers.
If you have a software development background, a CS degree, or several years of development experience, SDET is the right target. The pay differential is substantial and the work is genuinely interesting at a technical level. The interview process is harder but your existing skills transfer directly.
One thing to note: the QA Automation Engineer title is where most career growth happens for people who enter as QA Engineers and want to move up without pivoting to pure development. Adding automation skills to a QA Engineer foundation is a reliable path to higher compensation and more interesting work.
What this means for your job search
Stop filtering by title. Filter by requirements. When you're building your application list, run two quick checks on every posting: does the actual work described match my current skill level, and does the coding expectation match what I can actually demonstrate in an interview?
If you're targeting QA Automation Engineer roles, your portfolio needs to show test code. Not descriptions of automation work. Actual test files on GitHub, structured cleanly, with a readme that explains what the tests do and how to run them. A hiring manager wants to see test code that a developer would respect: readable, maintainable, thoughtfully organized.
If you're targeting SDET roles, you need that plus evidence of engineering judgment. Framework design decisions you made and why. Infrastructure work. Ideally, something you built that other people used. The SDET interview will probe deeper than "can you write a Playwright test" so be ready to discuss design tradeoffs.
If you're targeting QA Engineer roles, your portfolio should show quality thinking: well-written bug reports, test plans for non-trivial features, examples of edge cases you caught that mattered. Automation is a bonus, not the core pitch.
The market pays meaningfully more for roles further up the engineering spectrum. That's not an argument that traditional QA work is less valuable; good product quality judgment is genuinely hard to find. It's a factual observation about what the market currently prices. Knowing which direction you're building toward helps you invest your learning time in the right places.
The three titles describe three different jobs. The chaos comes from the fact that nobody agreed on which title goes with which job. Now that you know what to look for in the requirements, the chaos stops being a problem.
→ See also: QA Career Path: From Junior to Senior QA Engineer | QA Automation Engineer Job Description: What Companies Actually Want | How to Build a QA Portfolio That Gets You Hired (GitHub + Playwright) | Manual QA vs Automation QA: Which Pays More in 2026?
