From QA to Quality Engineer: How the Role Actually Changed
A quality engineer is a software engineer whose product is the quality of other software — they write test infrastructure, wire CI signals, read production telemetry, and own how the team learns about defects. That definition has very little to do with the manual tester job it grew out of, and it overlaps only partly with the SDET role that bridged the two. The shift from QA to SDET to quality engineer is now far enough along that the three titles describe genuinely different jobs, hired against different scorecards, paid on different bands.
This brief covers what changed, how a quality engineer's scope differs from an SDET's, what major employers actually put in their job postings, and what the 2026 hiring data shows about where the discipline is heading.
Key takeaways
- Manual QA validated software against requirements. Quality engineers build the systems that decide whether the team can ship safely.
- The SDET role was created at Microsoft in the 1990s and formally retired there in 2014, when the company merged dev and test into a single "Software Engineer" track.
- The 17th annual World Quality Report (Capgemini / Sogeti / OpenText, November 2025) found 89% of organisations are piloting or running Gen-AI-augmented QE workflows — but only 15% at enterprise scale.
- Modern QE owns four surfaces: pre-merge test signal, CI pipeline health, production telemetry, and developer experience for testing.
- LinkedIn lists 100,000+ open quality engineer roles in the US as of May 2026, with 14,000+ remote, though most of those are still hardware/manufacturing QE — software QE listings cluster under "SDET", "QE", or "test platform engineer".
What is a quality engineer?
A quality engineer (QE) is responsible for the systems that produce confidence in a software release — test frameworks, CI gates, observability for the test suite itself, and the feedback loops that turn production incidents into prevented regressions. Where a manual QA tester answered does this build pass?, a QE answers how does this team know whether any build is safe to ship, at any moment, without anyone manually checking?
That reframing matters because it changes what a QE produces. The output of a manual tester is a defect log. The output of an SDET is automated tests. The output of a quality engineer is closer to a platform — the pipelines, harnesses, dashboards, and conventions that the rest of engineering relies on to ship without breaking things. A QE who never touches a test case directly, but who keeps the team's CI green and its flake rate under 2%, has done their job.
The title is not universally adopted. Some organisations still call this person an SDET, others a test platform engineer, others a developer productivity engineer focused on test infrastructure. The work is more consistent than the naming.
QA, SDET, and QE: how they actually differ
The three roles are often discussed as a linear evolution. In practice they exist side-by-side at most large companies, doing related but distinct work. The clearest way to see the difference is by what each role owns end-to-end.
| Dimension | Manual QA | SDET | Quality Engineer |
|---|---|---|---|
| Primary output | Executed test cases, defect reports | Automated test suites against features | Test infrastructure, CI gates, quality signals |
| Code expectation | Light — scripting, SQL, occasional automation | Production-grade code in the team's main language | Production-grade code, often across services and tooling |
| Where they sit | Centralised QA team or embedded reviewer | Embedded in a product team | Embedded in a product team, platform team, or both |
| Testing posture | Black-box, requirements-driven | Mostly white-box and integration | Whole-stack: unit signal, contract, E2E, production |
| Cares about | Defect escape rate, test coverage | Test reliability, automation throughput | Lead time, change failure rate, MTTR, flake rate |
| Failure mode if absent | Bugs ship | Regression rate climbs | Team loses ability to ship confidently |
Some clarifications on that table.
Manual QA still exists, and that is fine. Domain-heavy products — healthcare, banking, ad-tech with complex business logic, regulated workflows — benefit from testers who understand the user behaviour better than any automation can. The mistake is treating manual QA as a step on a career ladder rather than a discipline with its own depth.
SDET overlaps heavily with QE. In 2026, the distinction is increasingly soft. A 2026 industry overview from Maruti Tech describes SDETs as having moved through phases, currently sitting at what they call the "Quality Engineering phase" — owning end-to-end quality including test strategy, CI/CD integration, observability, and production validation. Many companies use SDET and QE interchangeably; others reserve QE for more senior or more platform-leaning work.
The QE role is broader than testing. This is the load-bearing point. Quality engineers are increasingly expected to influence production observability, incident retrospectives, developer ergonomics around testing, and architectural decisions about testability — not just to write tests.
A short history: how we got here
The traditional QA model emerged from waterfall. Testing was a phase. Testers worked from spec documents, ran cases in sequence, filed defects. As agile compressed cycles in the 2000s and CI made daily deployments normal, that model started failing on cadence — there was no slot in a two-week sprint for a four-week regression pass.
Two structural moves followed.
Microsoft pioneered SDET, then killed it. Microsoft introduced the Software Development Engineer in Test role in the 1990s, eventually running a roughly 2:1 SDE:SDET ratio across the company. In July 2014, as part of an 18,000-person layoff, Microsoft formally retired the SDET title and folded it into a unified "Software Engineer" track under a model they called combined engineering. Azure adopted the same model later that year. Developers absorbed the test workload, with the explicit goal of forcing testing further left into unit and integration scope. The change was driven less by tooling and more by incentive design — the team that writes the test owns the cost of writing it. (Pragmatic Engineer's writeup from Microsoft engineers who lived through the change is the canonical source.)
Google kept the split, but evolved it. Google maintained two distinct roles: Software Engineer in Test (SET) and Test Engineer (TE), described in Google's testing blog as complementary rather than hierarchical. Google's SET job postings ask for production code skills, design-review participation, and authorship of test frameworks rather than test cases — closer to what most companies now call quality engineering. Salary ranges in 2025–2026 US postings for Google SET roles fall in the $141,000–$202,000 band before equity, which puts the work on the same compensation track as standard software engineering, not below it.
The combination of these two patterns shaped what the rest of the industry inherited. Pure manual QA shrank. The SDET title proliferated, then started absorbing platform-engineering and observability work that did not fit cleanly under "automation". A new "quality engineer" title emerged to describe the broader scope. Whether you call it QE or SDET in 2026 is more a recruiting convention than a real distinction.
What modern QEs actually own
Across mature engineering organisations, quality engineering work clusters around four surfaces. A QE may not own all four, but they understand how each one behaves and where their work touches it.
Pre-merge signal. Before code reaches main, what does the team learn about it? Unit test results, contract tests against dependent services, type-checking, lint, security scans. QEs own the speed and reliability of this signal — a 40-minute pre-merge suite that flakes 8% of the time is a worse quality signal than a 6-minute suite that flakes under 1%, even if the longer one technically covers more. Latency and trust are the metrics; raw coverage isn't.
CI pipeline health. Past merge, what gates does the change pass through before reaching production? Integration tests, E2E suites, performance regression checks, accessibility audits via Axe or Pa11y, visual regression diffs. QEs maintain these pipelines as infrastructure — versioned, monitored, on-call-able. Flake rate, queue time, and false-positive rate are tracked the way an SRE tracks latency.
Production telemetry. This is the surface that separates QE from automation engineering. Once code is in production, what does the team know? Error rates broken down by route, user, and tenant. Latency percentiles. Trace-level visibility into failing requests. QEs work with SRE and platform teams to make sure production signal is usable for quality decisions — feeding new test cases out of incident retrospectives, catching regressions that staging environments never surface. The World Quality Report 2025-26 found that 38% of organisations are now running shift-right pilots that use production telemetry to derive new test coverage, distinct from but reinforcing shift-left work.
Developer experience for testing. The most underrated surface. Can a developer write a meaningful integration test in under 10 minutes without reading documentation? Can they run the slow suite locally before opening a PR? Does the test failure message tell them which fixture broke? QEs treat this as a product problem — the engineering team is the user, the testing toolchain is the product.
A useful gut-check: a senior QE in 2026 is closer in shape to an SRE or platform engineer focused on test infrastructure than they are to a senior manual tester. The work rhythm — incidents, dashboards, runbooks, post-mortems — looks more like operations than verification.
The 2026 hiring picture
There is no clean public dataset of "software quality engineer" hiring in 2026 — the title fragments across SDET, QA Engineer, Quality Engineer, Test Engineer, and Developer Productivity Engineer. What can be observed:
- LinkedIn lists 100,000+ open Quality Engineer roles in the US (May 2026), of which 14,000+ are remote. Most are hardware, manufacturing, and medical-device QE — the software-QE share is smaller and lives under SDET and similar titles.
- Zippia's 2026 outlook projects roughly 30,600 new quality engineer jobs over the coming decade, with 10% growth from 2018-2028 — slower than software engineering overall but still positive.
- The World Quality Report 2025-26 surveyed more than 2,000 senior executives across 22 countries. 63% ranked Gen-AI as the top skill they want in their quality engineers, narrowly ahead of core quality engineering skills at 60%. Only 53% of testers in those organisations have actually received AI or ML training, so the gap is real.
- 50% of organisations in the same report said they lack AI/ML expertise in their QE function — unchanged from 2024, suggesting hiring has not closed it.
- 46% of organisations have introduced AI-focused roles within QE since 2024. These job descriptions tend to ask for prompt design, evaluation framework experience, and the ability to validate non-deterministic systems — work that did not exist in the QA job spec five years ago.
The signal in those numbers is fairly clear: demand is steady, the skill profile is moving toward AI and platform work, and most teams are slower than the trend they say they care about. That gap is what is creating openings.
What this means for QA professionals navigating the shift
For an individual currently in a QA seat who wants to move into modern quality engineering work, the move is not primarily about learning a new tool. It is about changing what they produce.
Stop producing defect logs as the main artefact. Start producing pull requests against the test suite, the CI configuration, or the test fixtures. The work that scales is the work that lives in the same repos developers do.
Pick one production signal and own it. Error rate on the checkout flow. P95 latency on the search endpoint. Accessibility violations in a key journey. Whatever it is, own the dashboard, write the alert, and start running a recurring review of what that signal is telling the team. This is what shifts the role from reactive to preventive.
Learn the team's primary language well enough to debug, not just to test. A QE who can open a stack trace, read the relevant code, and write a regression test that reproduces the bug is doing the work that has economic value. A QE who has to hand the bug back to a developer to investigate is still in the older model.
Treat the testing toolchain as a product. If onboarding a new engineer onto the test suite takes two days, that is a defect — file it, fix it, measure the improvement. The companies that hire well-paid QEs are the ones whose testing toolchain is treated like internal infrastructure.
The pattern that recurs across the World Quality Report's 2025-26 findings is that AI tools are amplifying existing capability rather than replacing it. Teams with strong QE function are getting 19% average productivity gains; teams without it are getting closer to zero. The differentiator is whether the underlying signal infrastructure exists for AI tooling to plug into.
How Crosscheck fits into a quality engineer's loop
Crosscheck is a Chrome extension for visual bug reporting — screenshots, screen recordings, console logs, and network logs captured in one pass and forwarded to Jira, Linear, ClickUp, Slack, or GitHub. For a quality engineer, the relevant value is at the messy end of the loop: the moment when something fails in exploratory testing or stakeholder review and that observation needs to become a reproducible artefact in the team's tracker.
A QE who is wiring production telemetry, owning CI gates, and treating their toolchain as a product still needs the bug-report surface to be fast and rich enough that nothing important gets lost between "I saw something weird" and "the developer can reproduce it". That is the slice Crosscheck handles — capturing the technical context (DOM state, network calls, console errors) at the moment of observation so the bug report does not become a forensic exercise later.
It is not test infrastructure and it does not pretend to be. It is the capture layer for human-observed defects, alongside the rest of the quality stack. For teams whose biggest remaining friction is the gap between noticing a bug and writing one up cleanly, that is enough to matter.
FAQ
What's the difference between QA and quality engineer?
QA traditionally validates software against requirements after development. A quality engineer builds the systems — test infrastructure, CI gates, production observability — that let a team continuously verify quality without manual gating. QA is a role; quality engineering is closer to a discipline that the role evolved into.
Is SDET the same as quality engineer?
In 2026, mostly yes. The titles are used interchangeably at many companies. Historically SDET emphasised test automation; modern QE emphasises platform and signal infrastructure. The overlap is now large enough that recruiting often treats them as one role with two names.
Did Google or Microsoft kill the test engineer role?
Microsoft formally retired the SDET title in 2014 and merged dev and test into a unified Software Engineer track under "combined engineering". Google kept its SET and TE roles as a complementary pair, with SET work that looks like modern quality engineering and TE work that looks like end-to-end and exploratory testing.
What does a quality engineer need to know in 2026?
Production code in the team's main language, CI/CD pipeline configuration, test framework design (unit, integration, contract, E2E), production observability tools (traces, logs, metrics), and increasingly LLM-based test generation and evaluation. The World Quality Report 2025-26 lists Gen-AI as the top desired QE skill, ahead of core quality engineering skills.
Are manual QA jobs disappearing?
Pure manual QA roles are shrinking in software companies, but exploratory and domain-driven testing has not gone away — it has moved into roles that combine testing with product or design depth, or into specialist QE-adjacent roles. The shift is more about what produces value than about which job titles exist.
Build the loop that lets your team ship without flinching
The quality engineer role exists because shipping confidently is now a systems problem, not a verification problem. The teams that treat it that way are the ones whose CI signals are trusted, whose production telemetry feeds back into the test suite, and whose bug reports arrive with enough context to be fixed the same day they are filed.
If your team is investing in the rest of the stack, Crosscheck is the piece that handles the human-observation end of the loop — so the bug your designer noticed in staging review does not get lost in a Slack thread before it reaches the developer who can fix it. It is free, with no usage caps, and it ships its reports to wherever your team already triages.
If you are thinking about the shape of your QE function more broadly, our writeups on the future of QA roles, becoming a QA engineer in 2026, and the best AI testing tools of 2026 cover the adjacent terrain in more depth.
