How to become an SDET (from manual or automation QA)

"SDET" has become one of the most-searched career moves in testing, and for good reason: it's where a lot of the demand and most of the money are heading. But most guides on becoming one are generic skill checklists that end in "enrol in our course." This one is the realistic path from where you actually are — a manual or automation tester in India — with honest timelines and no course pitch.

Let me start with what the role actually is, because the title gets thrown around loosely.

What an SDET really is (vs a tester)

SDET stands for Software Development Engineer in Test. The key word is engineer. An SDET isn't a tester who occasionally writes scripts — they're a software engineer whose specialism is quality. They write production-grade test code, build and own automation frameworks, and sit close to the development team, often contributing to how quality is built into the product rather than checked after the fact.

The practical difference from a QA Engineer:

• A QA Engineer focuses on test design and execution; coding is helpful but not the core.
• An SDET is expected to build — frameworks, tooling, CI integration — to a real engineering standard. The coding bar is genuinely higher.

That higher bar is exactly why the role pays more and why demand outstrips supply: most QA teams report struggling to hire enough people who can write reliable test code. When demand beats supply, pay follows.

The skills you actually need

Here's the honest minimum. You don't need all of it on day one, but this is the destination:

• One programming language, properly — Java, Python, or JavaScript. Pick by what your target employers use (Java is still the most common in Indian test automation; Python and JS are rising). "Properly" means you can write, structure, and reason about real code — not just edit someone else's.
• An automation framework — Selenium or Playwright for web. Knowing both tends to command a premium over single-tool specialists (TestDino, 2026), so it's a good medium-term goal.
• API testing — REST Assured or Postman. Increasingly assumed for any serious SDET role.
• CI/CD basics — Git plus a pipeline tool (Jenkins, GitHub Actions); being able to run your tests automatically when code changes.
• Some CS fundamentals — for product-company SDET interviews especially, expect data-structures-and-algorithms rounds. You don't need competitive-programming depth, but you need to handle standard problems.

The order you build these in matters a lot, and that's its own guide — the automation testing roadmap lays out the exact sequence and what to safely ignore. This page is about the career move; that one is about the skill build.

The path from manual testing

This is the biggest group of people asking the question, so let's be specific. Going from manual testing to SDET is the longer of the two journeys, and the honest hard part is the coding ramp — there's no shortcut around becoming genuinely competent at programming.

A realistic progression:

1. 01Learn to code first. Before any framework, get comfortable with one language — variables, data structures, functions, OOP basics. This is the foundation everything else sits on, and the stage people most often try to skip (and then stall).
2. 02Add web automation. Selenium or Playwright, building real tests against actual applications, not tutorials.
3. 03Build a framework. Page Object Model, data-driven structure, reporting — a small but genuine framework you can put on GitHub. This is the single most important portfolio piece.
4. 04Layer in API testing and CI. REST Assured/Postman, then wire your suite into a pipeline.
5. 05Reshape your resume and start targeting SDET roles. Lead with the engineering work, not the manual history. (The QA resume mistakes guide covers this shift.)

Don't rush stages 1–2. Most failed transitions are people who learned a framework without really learning to code, hit a wall the moment a problem went off-script, and gave up. Build the foundation properly and the rest goes faster than you'd expect.

The path from automation QA

If you're already an automation tester, you're much closer than you think — you've cleared the coding hurdle. The gaps are usually:

• Framework ownership — moving from using a framework to being able to build and architect one.
• CI/CD depth — owning the pipeline, not just having your tests run in it.
• CS fundamentals — brushing up DSA for product-company coding rounds.
• Breadth — adding API testing or a second framework if you're missing them.

For most automation testers this is a few months of focused work, not a year. The automation testing roadmap covers the gaps in order.

How long does it really take?

Honestly: 6–18 months, depending on where you start and how consistently you put in the hours. From automation QA with solid coding, the lower end. From manual testing with no programming background, the higher end. Anyone promising "become an SDET in 30 days" is selling a course, not telling you the truth — and you should be suspicious of that the same way you'd be suspicious of any unverified claim. (That instinct, frankly, is the whole reason CareerIntel exists: most career "facts" online don't survive a fact-check.)

The single biggest variable isn't talent — it's consistency. An hour of real practice most days beats a heroic weekend once a month.

What the move is worth

The payoff justifies the effort for most people. SDETs earn a median around ₹9.45 LPA (PayScale, 2026), against a manual tester at roughly ₹3.7–4.3 LPA (Indeed ~₹3.69 LPA; Glassdoor Manual Tester ~₹4.34 LPA) — a premium often in the 50–90% range for someone moving from pure manual work. At product companies the ceiling is far higher, with senior total compensation (including stock) reaching ₹25–45 LPA. The full breakdown is in the SDET salary guide.

One honest caveat: if you genuinely dislike coding, don't force the SDET path for the money alone — it tends to end in burnout. The specialist (performance, security) and management tracks in the QA career roadmap may suit you better. The SDET move pays best for people who actually enjoy solving problems with code.

How to prove it in interviews

When you're ready, SDET interviews typically test three things: coding (DSA and problem-solving), test/system design (how you'd build a framework, handle flakiness and scale), and your real automation experience. The Selenium interview questions and API testing interview questions guides cover what gets asked, organised by experience level. The candidates who do best can talk concretely about frameworks they built — which is exactly why stage 3 of the manual path (build a real framework) matters so much.

The roadmap to becoming an SDET is learnable — the skills are clear and the path is well-trodden. The harder part is the targeting: knowing which companies are hiring SDETs for your background right now, what they pay for your level, and whether your profile reads like an SDET's yet. That research takes real, current effort to do well.