>_ Analyst Engineering
QA AnalystDeveloper Analyst Follow

QA Analyst to Automation Engineer (SDET): The Skills, the Timeline, and the Pay Gap

Written by Ahmed at Analyst Engineering, a Senior Technical Business Analyst with 10+ years in banking and payments delivery.

Cover for a career guide on moving from QA analyst to automation engineer or SDET, showing the pay step from the QA analyst band to the SDET band in the US and Canada.

Key takeaways

  • Moving from manual QA analyst to SDET typically pays 25 to 40 percent more at the same level, and the move takes 6 to 12 months of deliberate work for someone who already tests for a living.
  • The automation stack that gets QA analysts hired is narrow: one language, API tests first in Bruno or Postman and then in code, Playwright for a few critical UI journeys, CI in GitHub Actions, contract tests, and test data you control.
  • AI now writes test code in minutes, so the scarce skill in automation is test design: choosing what to test and defining the oracle that says what correct means.
  • A QA analyst who automates the API layer of their own team's regression pack has a stronger case for an SDET title than any certificate or tutorial project.
  • The step after SDET is test architect, which owns test strategy, environments, test data, and quality gates across teams rather than the volume of tests.

Moving from QA analyst to automation engineer, usually titled SDET (software development engineer in test), pays 25 to 40 percent more at the same level and takes 6 to 12 months of deliberate work for someone who already tests for a living. The stack is narrower than job ads suggest: one language (Python, TypeScript, or Java), API tests first in Bruno or Postman and then in code, Playwright for the few UI journeys that matter, a CI pipeline in GitHub Actions, contract tests, and test data you control. The QA analysts who make the jump fastest keep their real edge, test design, and let the code carry it.

On a payments programme I worked on in Montréal, the regression pack for each release was 412 manual test cases in a spreadsheet. Three QA analysts spent eight working days running it. One of them had started rewriting the API layer of the pack in pytest, on her own time, against the test environment. By the third release, 180 of those cases ran in eleven minutes on every merge, and the eight days became three. Within the year she had a new title and a new salary band.

What she had that tutorials do not teach was not Python. It was knowing which 180 cases were worth automating and what “correct” meant for each one. That test design skill is the core of API Testing and QA Mastery for BAs, which derives API tests from business rules rather than from screens, and it is the foundation the rest of this plan sits on.

What does the move from QA analyst to automation engineer actually look like?

The move changes your main deliverable from executed test cases and defect reports to maintained test code that runs without you, on every change. The thinking stays; the medium changes.

DimensionQA analyst (manual or functional)SDET / automation engineer
Main outputTest cases, execution evidence, defectsTest code in a repository, reviewed like product code
When tests runWhen a person runs them, per releaseOn every pull request and every deploy, in CI
Core toolsJira, Xray or Zephyr, Postman, SQLA language, Git, Playwright, pytest or JUnit, GitHub Actions
Measured onCoverage of requirements, defects foundSuite speed, flake rate, defects caught before merge
Works closest withBAs, product owner, UAT usersDevelopers, DevOps, the architect
What ruins your weekA late build and a fixed go-live dateA flaky suite nobody trusts

What does not change is the hard part: deciding what to test, at which layer, with which data, and what the expected result is. The split between those two jobs is laid out in QA analyst vs test engineer, and the QA foundation itself in what a QA analyst does.

Which programming language should a QA analyst learn for automation?

Learn the language your team’s developers already use for tests, because your code will be reviewed and maintained next to theirs. With no signal, pick TypeScript for web products (Playwright is TypeScript-first), Python for API and data work (pytest and requests), and Java for large banks with Java backends (JUnit 5 and RestAssured). Job ads repeat the same phrases: “strong experience with Playwright or Cypress”, “API automation using RestAssured or pytest”, “CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins)”, “contract testing (Pact)”. If you have never written a script, start with scripting checks in Python and Git for analysts before any framework.

Why should automation start with API tests instead of UI tests?

API tests are faster, more stable, and closer to the business rules than UI tests, so they give the most protection per hour of effort. A UI test that checks a payment limit clicks through four screens and breaks when a button moves; the API test posts one request and asserts one rejection code. Build API tests first in Bruno or Postman using the API testing guide and API test case design, add request chaining and scripts, then port the best of them to code. Playwright comes later, for the five to ten journeys that must work end to end.

How much more does an SDET earn than a QA analyst?

An SDET typically earns 25 to 40 percent more than a manual QA analyst at the same level. The figures below are indicative 2026 base salary, permanent roles, large cities.

Role and levelUS (USD)Canada (CAD)UK, London (GBP)Eurozone (EUR)
QA analyst, mid72k to 92k62k to 80k36k to 48k42k to 52k
QA analyst, senior90k to 115k78k to 98k48k to 62k52k to 65k
SDET, junior80k to 100k70k to 85k40k to 50k45k to 55k
SDET, mid100k to 130k85k to 110k50k to 65k55k to 68k
SDET, senior130k to 160k105k to 130k65k to 85k68k to 85k

The honest reading: a mid QA analyst who lands a mid SDET title gains most of that 25 to 40 percent immediately. The trap is the senior manual tester offered a junior SDET title: US$80k to US$100k against a current US$90k to US$115k is flat or a cut. Negotiate the level, not only the number, because your test design experience is senior even if your code is not. Banking and capital markets in New York or London typically add 10 to 20 percent. The premium comes from scarcity: plenty of people can write a Playwright script, few can also decide which tests are worth writing.

To check your market, read posted ranges in pay transparency jurisdictions (New York, California, Colorado, Washington, Illinois and several other US states; British Columbia and, since January 1, 2026, Ontario for employers with 25 or more employees; the EU as member states implement the Pay Transparency Directive). In the UK, ITJobsWatch shows permanent rates by keyword such as “SDET” or “Playwright”. The annual Robert Half, Hays, and Michael Page salary guides help, and so does asking two people one level above you what their band is. The full cross-role table is in the analyst salary guide for 2026.

What does AI change for automation engineers?

AI writes test code quickly, so the value in automation has moved to test design and oracles. Ask an assistant for a Playwright spec from a recorded flow and you get one in minutes. It asserts what the page shows today, which means it passes for the bug and keeps passing forever. I call those mirror tests, and developer testing in the AI era shows how to spot and replace them.

This is good news for a QA analyst. An SDET whose only skill is typing framework code is exposed. A QA analyst who can derive tests from the rule, name the oracle (the source that says what correct means: the rulebook, the spec, the reconciliation total), and review generated test code for mirror assertions is exactly who teams now need. Give the model the requirement, the boundaries, and the expected results, withhold the implementation, and review what comes back. The same shift for developers is mapped in the developer’s job when AI writes the code.

What do real QA to SDET moves look like?

The cases below are composites of moves I have watched on delivery teams, with details changed.

A manual tester at a UK bank to SDET (£40k to £58k)

Daniel was a mid manual tester on a London retail bank’s payments team, earning £40k. He spent nine months building a pytest suite against the bank’s payment status API, starting with 30 cases lifted from his own regression pack, then negative cases from negative test design, then an idempotency check for duplicate submissions. He negotiated one day a sprint for it once the suite caught a real defect. He landed an internal SDET role in the same bank at £58k. What he would do differently: put the suite in the team’s GitLab CI in month two, not month six, because nobody valued it until it ran on every merge.

A QA analyst in Montréal to automation engineer (C$68k to C$92k)

Mélanie was a QA analyst at a Montréal insurance software company on C$68k. She moved her Bruno collections to TypeScript, added Playwright for three quote-to-bind journeys, and wired both into GitHub Actions with JUnit reports. Seven months in, she had a public repository that tested a public API with the same patterns she used at work, because her employer’s code was confidential. She was hired as an automation engineer at a Montréal fintech at C$92k. What she would do differently: apply to her own company’s automation team first; it opened a role two months after she left.

A business analyst who became an SDET in Denver

Marcus was a mid business analyst at a Denver health insurer on US$88k, the BA who wrote the acceptance criteria and ran UAT. He taught himself Python by automating his own acceptance tests against the claims API, then added contract tests between two services he had specified. It took twelve months. He landed an SDET role at a Denver SaaS company at US$108k (Colorado job ads carry ranges, which helped him anchor). What he would do differently: he nearly accepted a junior SDET offer at US$85k, which would have been a cut; his requirements background justified a mid level title, and the second employer saw that.

What is the month by month plan from QA analyst to SDET?

The plan below assumes five to eight hours a week, plus whatever sprint time you can negotiate. Each month ends with an artifact you can show.

  1. Month 1: one language and Git. Write five small scripts that check real test outputs: compare two CSV exports, validate a JSON response against expected fields, count rejected records. Commit each with a clear message. Artifact: a repository with five scripts and a README.
  2. Month 2: API tests in Bruno or Postman. Take one API your team owns and write 30 tests derived from its rules: happy paths, boundaries, invalid values, missing fields, auth failures. Chain requests and assert on the response body, not only the status. Artifact: a collection where every test names the rule it proves.
  3. Month 3: the same tests in code. Port the 15 most valuable tests to pytest, Playwright’s request API, or RestAssured, with fixtures and a test data builder so no test depends on another. Artifact: a suite that runs green from a clean checkout with one command.
  4. Month 4: CI. Run the suite in GitHub Actions on every pull request, publish a JUnit report, keep secrets out of the repo. Follow running API tests in CI. Artifact: a pipeline badge and a failing build you caused on purpose.
  5. Month 5: Playwright for critical journeys. Automate five to ten UI journeys with page objects and stable locators, and run each 50 times to measure flake. Artifact: a UI suite with a recorded flake rate under 2 percent.
  6. Month 6: contracts, events, and retries. Add one contract test between two services, one event check using Kafka testing, and one retry check from idempotency testing. Artifact: three tests that catch integration bugs unit tests cannot.
  7. Months 7 to 12: automate your own team’s regression. Pick one area of the real regression pack, automate its API layer, and report hours saved per release. Artifact: the before and after, in hours and escaped defects, which is your promotion case.

Here is the shape of a month 6 retry test. It is short, and every line encodes a rule rather than a screen:

def test_duplicate_refund_with_same_key_returns_same_refund(api, captured_payment):
    body = {"amount": 1500, "currency": "CAD"}
    headers = {"Idempotency-Key": "refund-7f3a"}
    first = api.post(f"/payments/{captured_payment}/refunds", json=body, headers=headers)
    second = api.post(f"/payments/{captured_payment}/refunds", json=body, headers=headers)
    assert first.status_code == 201
    assert second.json()["refund_id"] == first.json()["refund_id"]

For month 6, the event side is where QA analysts most often stall. Automate Kafka Validation with Postman covers validating Kafka events from Postman, which is a practical bridge before you write consumers in code. To practise on a realistic system first, run the Validate an Event Flow mission in the Labs: you follow one payment across Kafka topics, consumer logs, and a dead letter queue. A free account saves your progress and unlocks the solution and self-assessment, and the Become a Technical Analyst track orders the missions for you. For the wider technical base (reading code, SQL, delivery tools), The Tech Skills Guide for BAs fills the gaps a QA background leaves.

What mistakes stall the move from manual QA to automation?

  • Starting with UI automation. Selenium or Playwright on day one produces brittle tests and a bad first impression. Start at the API layer.
  • Automating the manual pack one to one. Manual cases were written for humans. Rewrite them by layer and risk; many belong at the API, some should be deleted.
  • Tutorial loops. Three courses and no repository is the most common failure I see. Your team’s API is a better teacher than any course.
  • No CI. A suite that runs on your laptop is a hobby. A suite that blocks a bad merge is a job.
  • Tolerating flaky tests. One flaky test teaches the team to ignore red builds. Quarantine it the same day and fix the cause.
  • Collecting certificates instead of commits. ISTQB (International Software Testing Qualifications Board) Foundation is fine on a CV, but no hiring manager I know chose an SDET for it over a repository. The ranking is in which analyst certifications are worth it.
  • Leaving before asking. The cheapest move is internal, as changing role inside your company explains. Ask your test lead for automation work before you apply elsewhere.

Is test architect the next step after SDET?

Test architect is the usual next step for SDETs who prefer designing the system of tests over writing more of them. The role owns test strategy across teams, environments, test data management, contract testing standards, and quality gates in CI. Indicative 2026 base salary, permanent, large cities: US$155k to US$190k, C$125k to C$150k, £80k to £100k in London, €80k to €100k in the eurozone. It usually comes after three to five years as an SDET.

It is not the only branch. Some SDETs discover they prefer shaping requirements and move to technical business analysis. Others want to own features and look at moving from technical analyst to software developer. If you are still deciding between testing and analysis, QA tester to business analyst covers the other direction, and the career paths map shows all of them. Score yourself first with the technical analyst skill matrix and the roadmap.

The takeaway

The QA analyst to SDET move is one of the best-paid sideways steps in delivery: 25 to 40 percent at the same level, in 6 to 12 months, with no degree required and no reset of your seniority if you negotiate the level. The stack is small. The differentiator is the thing you already have, knowing what to test and what correct means, which matters more now that AI writes the test code.

Start with the API layer of your own team’s regression pack, and use API Testing and QA Mastery for BAs to derive those tests from rules. If you want a second opinion on your plan, your repository, or an offer, book a 1:1 Tech BA Coaching Call. The free downloads are a good first step, and everything else is in The Tech BA Toolkit. More on the testing side of the role lives in the QA Analyst hub.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Software Testing, Test Automation, Career Growth, QA, Banking

About the author

Analyst Engineering is written by Ahmed, a Senior Technical Business Analyst with 10+ years of banking and payments delivery experience: ISO 20022 and SWIFT messaging, payments API integration, Kafka event validation, and production support. Every article comes from real delivery work, and each one is reviewed and updated as tools and standards change.

Go deeper on this

Not ready to buy? The free downloads are a no-cost place to start, and every article here stays free.

Free account

Practice on the Labs, keep your progress

A free account, no password: an email link signs you in. It saves your steps and self-assessments on the Labs, shows your missions on a dashboard, unlocks the solutions, and, if you tick the box, sends you new missions and articles when they ship.

Your email is used to sign you in. Nothing else, unless you ask. Privacy.