SDET Roadmap: From Automation Engineer to Quality Leader

Most SDET career advice stops at “learn Selenium, then learn Playwright”. That gets you a job. It does not get you to the point where you shape how a whole engineering organisation thinks about quality, which is where the most interesting and best-paid SDET work is.

This SDET roadmap lays out five stages, from your first automation role to quality leadership. For each one you will find the skills to build, what the role is responsible for, and the signal that you are ready for the next step.

What does an SDET do?

A Software Development Engineer in Test (SDET) is an engineer who builds the systems that prove software works: automation frameworks, test infrastructure, CI quality gates and the tooling that lets developers test their own code. An SDET writes production-quality code, but the product they build is confidence in every release.

	Manual QA engineer	Automation tester	SDET
Main output	Test cases and bug reports	Automated test scripts	Test frameworks, infrastructure and quality gates
Coding	Little or none	Scripting	Production-level engineering
Works mostly with	Product and QA	QA team	Developers, DevOps and architects
Scope	Features	Test suites	The whole delivery pipeline

The SDET roadmap at a glance

Stage 1: Automation foundations

• One programming language, properly: Java, Python or TypeScript. Data structures, OOP, error handling, reading other people’s code.
• UI automation: Playwright or Selenium, with a solid locator strategy and waits that do not depend on sleeps.
• API testing: HTTP fundamentals, REST Assured, requests or Playwright’s API client, schema validation.
• Git and code review: branches, pull requests, writing reviewable commits.
• Testing fundamentals: test design techniques, the test pyramid, writing clear bug reports.

Ready for the next stage when: your tests are trusted. When they fail, people believe there is a real problem.

Stage 2: SDET

• Framework design: page objects or screenplay, fixtures, configuration per environment, reusable helpers.
• CI/CD: running suites in GitHub Actions, GitLab CI or Jenkins, parallel runs, reports and artefacts.
• Test data and environments: seeding, cleanup, mocks and service virtualisation.
• Flaky test engineering: diagnosing timing, ordering and data causes instead of adding retries.
• Docker basics: running dependencies locally and in CI.

Ready when: other engineers add tests to your framework without asking you how.

Stage 3: Senior SDET

• Test architecture: deciding what is tested at unit, contract, API and UI level for a whole system.
• Contract and integration testing: Pact or similar, plus testing event-driven and async flows.
• Performance testing: k6, JMeter or Gatling, with realistic load models and clear pass criteria.
• Observability for testers: logs, metrics and traces to debug failures and verify production behaviour.
• Testing AI features: LLM testing, evaluation sets and prompt regression suites.

Ready when: you are invited to design reviews before code is written, because your input prevents defects.

Stage 4: Lead or Staff SDET

• Quality strategy across several teams, aligned to business risk rather than test counts.
• Platform thinking: shared test infrastructure, internal tools and paved roads other teams adopt.
• Metrics that matter: escaped defects, change failure rate, time to restore, suite reliability. See our guide to quality metrics engineering teams should track.
• Mentoring and hiring: growing other SDETs and raising the bar in interviews.
• Influence without authority: getting teams to change habits because the evidence is clear.

Ready when: teams you do not work in use the standards and tools you created.

Stage 5: Quality leader

• Quality culture: developers own testing; QA enables rather than gates.
• Investment decisions: where to spend on automation, tooling and people for the biggest risk reduction.
• Business risk: translating quality signals into language executives act on.
• Scaling quality: how to build quality at scale across engineering teams.

Skills by stage

Skill area	Stage 1	Stage 2	Stage 3	Stage 4	Stage 5
Coding	Solid basics	Framework code	Architecture	Platform tools	Reviews direction
Test design	Techniques	Suites	System strategy	Org strategy	Risk portfolio
CI/CD	Runs tests	Owns pipeline stage	Quality gates	Org-wide standards	Delivery metrics
AI in testing	Uses AI tools	Reviews AI output	Tests AI features	Sets AI policy	AI investment
People	Learns	Shares	Mentors	Leads and hires	Builds culture

Common mistakes on the SDET path

• Collecting tools instead of going deep in one language and one framework.
• Writing many tests nobody trusts instead of fewer reliable ones.
• Hiding flaky tests behind retries rather than fixing causes.
• Measuring success by test count rather than defects prevented.
• Avoiding conversations with product and business, which caps you at Stage 3.

Keep your fundamentals sharp with five-minute challenges in the QA Bash Daily Testathon, and if you are wondering how AI changes this path, read will AI replace QA engineers.

Bookmark