Manual QA → SDET: the 90-day roadmap

Who this is for

Manual or functional testers with roughly two to six years of experience who want to move into automation while holding down a full-time job. The plan assumes 30 focused minutes a day — about three and a half hours a week. Not weekend heroics.

If you can give it more, you will move faster. But the plan is built for the amount of time people actually have, because a plan you abandon on day nine is worth nothing.

Read this first: you are not starting from zero

Manual testing already taught you the expensive part. You know how software actually breaks. You know which edge case will embarrass someone in production. You know where real users get confused and click the wrong thing. That judgment takes years and no course hands it to you.

What you are missing is a language to write it down in. That part takes months, not years. Loops, async, locators, a framework. Hard, but finite.

I know because I walked this road: a Mechanical Engineering degree, manual testing on kiosk software, and today a Senior SDET role testing AI agents in production. The path works. It just needs ninety focused days.

The stack: pick once, stop debating

JavaScript moving into TypeScript, Playwright, Git and GitHub, and one CI tool — GitHub Actions or Jenkins. That is the whole list.

Why this one: it is what modern job descriptions ask for, the setup is fast enough that you are writing tests on day one rather than fighting configuration, and Playwright's documentation is the best in the business.

Skip for now

Java and Selenium — unless a company you are specifically targeting demands it. Mobile automation. Performance testing. Certification courses. None of these get you the first automation job faster, and each one costs you weeks.

Days 1–30: the JavaScript a tester actually needs

You are a tester learning to code, not a developer starting over. Learn the parts you will use every day and leave the rest.

Variables, functions, arrays and objects, loops.
Then spend real time on async/await and promises. Async is roughly 80% of automation pain. Every "why is my test passing when the page hasn't loaded" question traces back to it.
Git basics: clone, branch, commit, push, open a pull request. Nothing clever.

Rhythm: four days a week learning, two days writing tiny scripts of your own. Reading code is not the same as writing it.

Day 30

A small script that reads a JSON file of test results and prints a pass/fail summary. Unglamorous on purpose — it proves you can handle data, loops, and file input.

Skip

Deep JavaScript theory, closure debates, prototype chains. DSA grinding. Framework wars.

Days 31–60: Playwright and TypeScript for real

Day 31 is when the first Playwright test gets written. Ready or not.

Locators, auto-waiting, assertions, fixtures, and the Page Object Model.
Practise against public demo applications, never your employer's product. Good targets: SauceDemo, the-internet by Selenium HQ, Restful Booker, and Playwright's own TodoMVC demo.
Add API tests using Playwright's request context. A large share of real testing happens below the UI.
Convert eight to ten of your existing manual test cases into automated specs. Your manual suite is your syllabus — you already know what to check.

Day 60

A public GitHub repository with 10 or more green tests and a README that shows the HTML report. The repo matters more than the count.

Skip

Chasing 100% coverage of a demo site. Depth of understanding beats test count, and every interviewer can tell the difference.

Days 61–90: CI, flake discipline, and the job layer

Run your suite in CI on every push. Add retries, and traces on failure so you can see what happened rather than guess.
Fix one flaky test properly — find the root cause instead of adding a wait — and write the story down. That story is interview gold, because almost nobody can tell it convincingly.
Rewrite your resume around what you built.

The resume line that works

Compare these two:

Completed certification in automation testing tools.

Built and maintained a Playwright/TypeScript suite running in CI on every push, including tracing and retry handling for flaky specs.

The second one describes a thing that exists. The first describes a receipt.

Day 90

A green pipeline badge on your repository, a rebuilt resume, and five interview answers drawn from your own project rather than from a tutorial.

The five mistakes that stall people

Tool-hopping. Ninety days on one stack beats thirty days on three.
Collecting courses with no repository to show for any of them.
Learning to code without testing anything. You are a tester learning code, not a developer starting from scratch.
Waiting to feel ready. Day 31 arrives whether or not you feel prepared. Write the bad first test.
Practising on your employer's application. Use public demo targets. Keep work and learning cleanly separate — it protects you and it makes your repo shareable.

A weekly rhythm that survives a full-time job

Thirty minutes a day, six days a week. Spend one of those sessions reviewing what you wrote and pushing it to GitHub.

If you miss a day, skip it. Never try to catch up with a four-hour Sunday — that is precisely how streaks die, and the streak is the only thing that matters here.

The day-90 scorecard

10 or more tests green in a public GitHub repository
The suite runs automatically in CI
One flaky test fixed, with the root cause written down
A resume rebuilt around Playwright and TypeScript, with real specifics
You can explain your locator strategy out loud, without notes

If this was useful, I write more of it — mostly about testing AI features and Playwright craft. It lives on the writing page, and I post twice a week on LinkedIn.

Want this offline? Use your browser's print or "save as PDF" — the page is formatted for it.