How to become an SDET / QA Engineer

A complete, honest roadmap for the skills SDET and QA engineers actually use, from testing fundamentals and test design through automation programming, UI and API testing, CI/CD, performance, quality strategy, and AI-assisted testing. It runs top to bottom, foundational to advanced, so you always know what comes next. Free to read, no signup required.

1. 01

   Step 01Testing foundations & the QA mindset

   Before any tool, understand what quality actually means and how testing fits the software lifecycle. The mindset (curiosity, skepticism, and a habit of thinking about how things break) is the real foundation.

   • What quality means: The difference between verification (did we build it right?) and validation (did we build the right thing?), and QA as risk reduction rather than gatekeeping.
   • Types of testing: Functional vs non-functional, black-box vs white-box, and the levels: unit, integration, system, and acceptance.
   • The test pyramid: Why many fast low-level tests and fewer slow end-to-end tests is a healthier balance than the inverse.
   • SDLC & where testing fits: How testing weaves through agile development, and the idea of shifting testing earlier (“shift-left”).

   SDET and QA overlap but differ in emphasis: QA centres on quality strategy and test design; SDET adds building the automation and tooling. The strongest engineers do both, which is why this roadmap covers the whole span.

   Verification vs validationTest levelsFunctional vs non-functionalTest pyramidShift-leftQA mindset
2. 02

   Step 02Test design techniques

   You can’t test everything, so testing well is about choosing the right cases. These techniques are timeless. They long predate any tool and outlast every framework.

   • Equivalence & boundaries: Equivalence partitioning and boundary-value analysis to cover many inputs with few well-chosen cases (bugs cluster at boundaries).
   • Decision tables & state transitions: Modelling combinations of conditions and system states so complex logic gets tested systematically.
   • Positive & negative testing: Confirming what should work and deliberately probing what shouldn’t. The negative cases catch the real bugs.
   • Exploratory testing: Skilled, unscripted investigation that finds issues rigid scripts miss. A core, durable QA craft.

   Equivalence partitioningBoundary valuesDecision tablesState transitionNegative testingExploratory testing
3. 03

   Step 03Manual & exploratory testing in practice

   Great automation is built on great manual testing instincts. Learn to test a real product by hand, write it up clearly, and report defects that get fixed.

   • Test cases & plans: Writing clear, repeatable test cases and organising them into plans and suites tied to requirements.
   • Defect reporting: Reproducible steps, expected vs actual, environment details, and evidence. A good bug report is a skill of its own.
   • Severity vs priority: Distinguishing how bad a defect is from how urgently it must be fixed. They’re not the same, and confusing them derails triage.
   • Requirements & acceptance: Reading requirements critically, spotting ambiguity early, and deriving acceptance criteria.

   Test casesTest plansBug reportingRepro stepsSeverity vs priorityAcceptance criteria
4. 04

   Step 04Programming for automation

   Automation is code. Becoming an SDET means becoming a real programmer, and this is the step that separates QA analysts from automation engineers.

   • A programming language: Pick one commonly used for test automation (Python, Java, JavaScript/TypeScript, or C#) and learn it properly.
   • Programming fundamentals: Variables, control flow, functions, data structures, and error handling: the building blocks of any test code.
   • OOP basics: Classes and objects, because most automation frameworks and patterns (like Page Object Model) are object-oriented.
   • Clean, maintainable code: Test code is real code. Keep it readable, DRY, and maintainable, or your suite rots into a liability.

   The most common ceiling for QA careers is stopping short of real programming. Investing here is what opens SDET roles and the better-paid, higher-skill end of the field.

   A languageControl flowData structuresOOP basicsError handlingClean code
5. 05

   Step 05Web & UI automation

   Automating a real browser is a core SDET skill, and the place where flaky, unmaintainable suites are born if you skip the principles beneath the tools.

   • How the DOM works: Enough of HTML and the DOM to locate elements reliably. This is the foundation for any UI automation tool.
   • Locators & selectors: Choosing stable, reliable selectors (roles, accessible names, test ids) over brittle ones tied to layout.
   • Synchronisation: Explicit waits and handling asynchronous UIs. Done wrong, this is the single biggest source of flaky tests.
   • Page Object Model: Structuring UI tests so element details live in one place and tests stay readable and maintainable. Selenium, Playwright, and Cypress are the common tool families.

   DOM & selectorsStable locatorsExplicit waitsPage Object ModelSelenium / Playwright / CypressFlakiness
6. 06

   Step 06API testing

   APIs are faster, more stable, and closer to the logic than the UI. API tests are often the highest-value automation you can write.

   • HTTP & request/response: Methods, status codes, headers, and JSON payloads: the vocabulary of every API test.
   • Validating responses: Asserting status, body, and schema, and testing the error and edge cases as thoroughly as the happy path.
   • Contract testing: Verifying that services agree on the shape of their interfaces so integrations don’t silently break.
   • Auth & data setup: Handling tokens and auth in tests, and setting up and tearing down test data reliably.

   HTTP & JSONStatus codesSchema validationContract testingAuth in testsTest data
7. 07

   Step 07Database & backend testing

   Many defects live in the data, not the UI. Being able to test at the database and service layer makes you far more effective.

   • SQL for testers: Querying data to verify what the application actually stored, and setting up precise test states.
   • Data validation: Checking integrity, transformations, and that operations persisted the right thing.
   • Test data management: Creating, isolating, and cleaning up test data so tests are independent and repeatable.

   SQLData validationTest data managementData integrity
8. 08

   Step 08Test frameworks & suite structure

   Individual scripts don’t scale. A real SDET builds and maintains a framework: the structure that keeps hundreds of tests fast, reliable, and readable.

   • Test runners & assertions: Organising tests, expressive assertions, and clear pass/fail output.
   • Fixtures & setup/teardown: Shared setup, teardown, and lifecycle hooks so tests stay isolated and DRY.
   • Parameterisation & data-driven tests: Running the same logic across many inputs without copy-pasting tests.
   • Reporting: Readable reports and artefacts (screenshots, logs) that make failures diagnosable at a glance.

   Test runnersAssertionsFixturesData-driven testsReporting
9. 09

   Step 09CI/CD integration

   Tests that only run on your laptop don’t protect anyone. Wiring automation into the pipeline is what makes it a real quality gate.

   • Running tests in CI: Triggering suites on every push or pull request, and gating merges on results.
   • Parallelisation & speed: Splitting tests across runners and keeping feedback fast enough that people actually wait for it.
   • Handling flakiness: Diagnosing and eliminating non-deterministic tests. A flaky suite that cries wolf gets ignored, which is worse than none.
   • Environments: Managing test environments, containers, and configuration so runs are consistent.

   CI pipelinesMerge gatesParallelisationFlakiness controlTest environments
10. 10

    Step 10Performance & load testing

    Beyond “does it work”, quality includes “does it hold up”. Performance testing is a distinct, valuable skill within the SDET remit.

    • Core concepts: Throughput, latency, concurrency, and percentiles: the vocabulary of performance, and why averages mislead.
    • Load, stress & soak: Different goals: expected load, breaking point, and behaviour over sustained time.
    • Finding bottlenecks: Reading results to locate where a system slows or fails under pressure.

    Throughput & latencyPercentilesLoad / stress / soakBottleneck analysis
11. 11

    Step 11Non-functional & specialised testing

    The qualities users feel but rarely name, like security, accessibility, and compatibility, are increasingly part of the QA remit.

    • Security testing basics: Common vulnerabilities (injection, broken auth, XSS) and testing for them, with the OWASP Top 10 as a starting checklist.
    • Accessibility testing: Verifying keyboard operability, semantics, and contrast so products work for everyone (and meet legal expectations).
    • Cross-browser & cross-device: Ensuring behaviour holds across the browsers, devices, and screen sizes real users have.

    Security basicsOWASP Top 10Accessibility testingCross-browserCross-device
12. 12

    Step 12Quality strategy & leadership

    Senior SDET/QA work is about strategy, not scripts alone. It means deciding what to test, how much, and how to embed quality across a team.

    • Test planning & risk: Risk-based testing: focusing effort where failure would hurt most, rather than testing everything equally.
    • Quality metrics: Meaningful signals (escaped defects, coverage as a signal, flaky-test rate) versus vanity numbers.
    • Shift-left & collaboration: Getting involved early, pairing with developers, and making quality everyone’s responsibility rather than a final gate.
    • Test strategy: Deciding what to automate vs test manually, and where in the pyramid each check belongs.

    Automating everything is not the goal. Testing the right things at the right level is. The judgement of what to test, and where, is the durable senior skill that no tool replaces.

    Risk-based testingTest planningQuality metricsAutomate vs manualShift-leftCollaboration
13. 13

    Step 13AI-assisted testing

    AI is entering QA from both sides: as a tool that helps generate and maintain tests, and as a new kind of system (AI features) that itself needs testing.

    • AI for test creation & upkeep: Using AI to draft test cases, generate data, and help maintain suites, with your review, since generated tests can assert the wrong thing.
    • Testing AI features: How to test non-deterministic systems: evaluation over exact assertions, guarding against prompt injection, and checking for harmful or wrong output.
    • Judgement over automation: AI accelerates test work but can’t decide what quality means for your product. That stays a human call.

    AI raises the value of testing judgement, it doesn’t lower it. Deciding what "correct" means, especially for probabilistic systems, is exactly the skill the fundamentals above build.

    AI test generationTest maintenanceTesting non-deterministic systemsEvaluationPrompt injection