A QA engineer is the person on a software team who learns how the product breaks before a customer does. They build the tests, checks and release signals that stop it breaking the same way twice. QA stands for quality assurance.
The title gets used for four different jobs, though, and the difference between them decides your pay, your ladder and how safe you are in the next reorg.
QA tester vs QA engineer vs SDET vs quality engineer
Most job boards treat these as one title. Postings don’t. Here is how they split once you read past the headline:
| QA tester | QA engineer | SDET | Quality engineer | |
|---|---|---|---|---|
| The question they answer | Does this feature work as specified? | Is this release safe to ship? | Can a machine tell us that on every commit? | Why do defects reach production at all? |
| Writes code | Rarely | Often, scripts and automated checks | Always, it’s a developer role | Yes, plus test infrastructure |
| Main output | Bug reports, test runs | Test plans, automation, release readiness | Frameworks, CI suites, tooling | Strategy, metrics, platforms developers use |
| Usually sits | At the end of the sprint | In the team, close to release | Next to developers | Across teams |
| Natural next step | QA engineer | QA lead or SDET | Software engineer or test architect | Head of QA, quality engineering director |
SDET means software development engineer in test. Microsoft ran the title at scale and then retired it in 2014, folding testers into a single engineer role.
A week in the job
Strip the adjectives from a dozen live postings and the work looks similar from Prague to San Francisco:
- Before code exists: sit in grooming and design reviews, write test cases and edge cases on the ticket. A Bloomreach QA posting puts it plainly: “You make the whole team better at testing, not the place work gets handed off to.”
- While it’s built: keep the automated suite in the pipeline green, chase flaky tests, add checks for the new feature.
- Before release: exploratory testing on real devices and browsers, the regression pass, a readiness summary somebody signs.
- After release: turn production incidents into regression tests, so the same bug can’t come back quietly.
The share of each depends on the company. A manual-heavy posting spends most of the week in the third bullet. A good product team pushes as much as possible into the first two.
The ladder above senior QA
Most explainers stop at “senior QA engineer”. The interesting decisions start there.
QA lead means two different things. In one company it’s a framework architect with no reports, the person who owns the test automation charter. In another it’s a player-coach who runs performance reviews, writes test plans and still builds automation. Ask which one before you accept the title, because only the second one prepares you for management.
QA manager or head of QA owns the quality strategy for several teams, the hiring of testers and SDETs, and the metrics leadership sees. The good version of this job changes how developers work. The weak version is a department that receives builds and returns verdicts.
Director or senior manager of quality engineering is where the role is being reinvented. Samsara’s senior manager posting describes self-service test platforms and escaped-regression rates, closer to a platform team than a test team. Machinify’s director posting asks for someone to rethink QA “where AI generates the majority of code”, at $225,000 to $250,000.
For a baseline, the US Bureau of Labor Statistics puts the median for software QA analysts and testers at $104,300 (May 2025). In Central Europe, the Bloomreach QA Engineer II role above lists 732,000 to 1,110,000 CZK base for Czechia.
Sideways moves are common: SDET into software engineering, quality engineering into platform or developer experience, and senior QA into release management or technical program management, where knowing how releases fail is a large part of the job.
The last gate gets cut first
QA work tends to sit at the end of the line, and the end of the line is visible only when something fails. When nothing fails, it looks like cost. That’s the structural risk of the role, and it has a history.
Yahoo removed its QA team around 2015 and had engineers ship without a QA safety net; IEEE Spectrum reported the company’s chief architect saying it was working. Microsoft’s 2014 move ended a setup where teams commonly ran about two developers per SDET, according to The Pragmatic Engineer. Atlassian went a different route years ago and renamed the job: its QA team does “quality assistance”, coaching developers to test their own work instead of testing it for them.
Read today’s postings closely and you can see the same pressure in the wording. Robinhood’s staff quality engineer posting calls the team “the final line of defense for product quality”. An Okta SDET posting asks you to “hold the release bar”, a paragraph later says you’ll work “as an engineer, not a gatekeeper”, and lists an on-call rotation further down. Machinify wants a director who can hold the bar on rigor “without becoming the bottleneck on velocity”, while code volume multiplies “without proportional headcount growth”. Each of those lines is reasonable alone. Together they describe a seat that collects the blame for escaped bugs and the blame for slow releases, with no added people to handle AI-written code. If you see two of these phrases in one ad, ask how many QA people the team had a year ago.
Moving upstream
In all of these versions the way out is to make quality something developers produce, and to be the person who built it.
- Get into grooming. Test cases and failure modes go on the ticket before anyone writes code. That’s where most bugs are cheapest to fix.
- Put QA in the estimate. If testing time isn’t in the estimate, QA will usually look like the reason a date slipped. I wrote about building an estimation checklist that names code review, QA and deployment explicitly.
- Own the gate as code. A CI suite developers run on every commit protects you better than a manual pass only you can run.
- Report escaped defects, not executed test cases. Leadership reads one number: how many bugs customers found, and whether it’s falling.
- Turn sign-off into a written risk statement. You describe what was tested and what wasn’t; the product owner accepts the residual risk. Your name on a release shouldn’t mean you personally guarantee it.
Self-check: gate or coach?
Answer each with yes or no:
- Do developers on your team write and run tests without being asked?
- Do you see features in design, or first in the “ready for QA” column?
- Does the sprint estimate include testing time?
- If you took two weeks off, would releases stop, or would the suite keep catching regressions?
- Can you say how many defects escaped to production last quarter?
- Does your manager know which incidents your tests prevented?
- Is your sign-off a written statement of risk, or your name on a release?
Mostly “no” means you are the gate, and the gate is what gets cut first in a reorg. Mostly “yes” means you’re building the system, as opposed to standing at the end of it, which is the profile that gets promoted into QA lead and quality engineering roles.
If you’re a QA lead choosing between people management and quality engineering, or trying to move out of the last-gate seat before a reorg moves you, that’s the kind of career decision I help people to think through in 1:1 career mentoring.
