Ninety days is enough to go from manual testing to a working automation framework on GitHub, if you give it about ten hours a week and pick one stack. This plan assumes you keep your current job, start with Playwright and TypeScript, and use your own team's regression suite as the project.
Why 2026 is the year to switch
Three things changed. Job posts for testers now list automation and API testing as the baseline rather than a bonus, so a manual-only profile gets fewer calls than it did. The tooling got easier: Playwright ships with a recorder, auto-waiting and a trace viewer, so a first useful test takes an afternoon instead of a week of setup. And AI assistants now draft code from a plain description of what to test, which makes your years of knowing what to test worth more, as long as you can read and fix what the assistant writes. The gap between a manual tester and an automation tester is smaller than it was. It still closes only with practice.
Pick one stack: Playwright with TypeScript
You will be tempted to learn Selenium with Java because that is what your company's suite uses. Unless you are being moved onto that suite next month, start with Playwright and TypeScript. Setup is one command, codegen gets you a readable first test, auto-waiting removes most of the flakiness beginners write, and the trace viewer shows you why a test failed with a screenshot and DOM snapshot at every step. TypeScript test code reads close to plain English. Once you understand locators, waits, page objects and CI in Playwright, picking up Selenium's version of each takes days. Our Playwright vs Selenium comparison goes into the trade-offs.
Keep your job while you do it
Budget ten to twelve hours a week: one hour on weekday evenings and two three-hour blocks at the weekend. That is roughly 140 hours over 90 days, which is enough for this plan if you spend the time building rather than watching. Three rules make it stick. Automate work you already do, so the practice replaces manual regression instead of adding to your day. Tell your lead what you are doing; most will let you run scripts against the test environment, and some will give you time for it. Keep a one-line log of what you automated each week. By day 90 it is your interview story.
What to automate first
Start with the regression cases you run by hand every release: login, the main create and edit flows, search, checkout or form submission, the report that always breaks. Pick flows that are stable, repeated and valuable. Leave the flaky, rarely run and visually complex cases for later. Where you can, automate the API behind a flow before the UI: an API test runs in milliseconds, fails for one reason, and teaches you the request and response structure the UI sits on. Then automate the UI on top, and assert the outcome, not every element on the page.
The 90-day plan, week by week
| Week | Focus | You end with |
|---|---|---|
| 1 | TypeScript basics: variables, types, conditionals, loops, functions | Twenty small scripts that run |
| 2 | Async and await, arrays and objects, reading error messages | A script that calls a public API and prints a field |
| 3 | Playwright setup, codegen, locators, your first three UI tests | Three passing tests on your team's test environment |
| 4 | Assertions, auto-waiting, trace viewer, breaking tests on purpose | A flaky test you fixed without a sleep |
| 5 | API testing in Playwright: request context, status codes, JSON assertions | Five API tests for your main flow |
| 6 | Fixtures: login once, reuse state, test data setup and teardown | UI tests that no longer log in by hand |
| 7 | Page Object Model, naming, folder structure | Your tests refactored into page objects |
| 8 | GitHub Actions: run on every push, upload the HTML report | A green CI run anyone can open |
| 9 | Parallel workers, retries, cross-browser projects, tagging | The suite on three browsers under ten minutes |
| 10 | Data-driven tests, environment config, secrets | One suite that runs against two environments |
| 11 | AI-assisted testing: Copilot or Cursor for drafts, Playwright MCP for exploration, checking the output | A written list of where the AI was wrong and how you caught it |
| 12 | README, cleanup, a three-minute walk-through, mock interviews | A repository you can explain from memory |
The thirteenth week is a buffer. Use it to finish whatever slipped, because something will.
Days 1 to 30: TypeScript and first tests
The first two weeks feel slow, because you are learning a language and have nothing to show for it. Push through by writing small scripts about your own job: a function that generates test data, a script that reads a CSV of test cases and prints the failures. In week 3 the tests start, and this is where most self-taught testers go wrong: they record with codegen and stop there. Recorded tests are a starting point. Rewrite each one by hand with getByRole, getByLabel and getByText locators, and add an assertion that proves the flow did what it should. Week 4 is about failure. Break a test, open the trace, and read the step where it failed until you can say in one sentence why.
Days 31 to 60: API testing, fixtures and CI
This month separates people who write scripts from people who build suites. Playwright's request context lets you call your application's API inside the same test file, so you can create data through the API, check it in the UI, and clean up afterwards. Fixtures remove the repeated login and setup code; a storage state saved once means every test starts already signed in. Page objects give the suite a shape a teammate can read. Then CI: push to GitHub, let the generated workflow run the suite on every push, and fix what fails in a clean environment, which is never quite what passed on your laptop.
Practical tip. From week 5, run your suite against the test environment every morning before stand-up and post the result in your team channel, even when it is three tests. A month of "automation: 14 passed, 1 failed, here is the bug" messages does more for your reputation than any certificate, and it makes the move to an automation role an internal conversation rather than a job hunt.
Days 61 to 90: framework, reporting and GitHub
Now the suite becomes a framework: parallel workers, retries for the tests that depend on a slow service, projects for Chromium, Firefox and WebKit, tags so you can run smoke tests separately from the full regression, and environment config so the same suite runs against staging and a local build. Week 11 is for AI tools, used with a check on everything. Let Copilot or Cursor draft a page object, then fix the locators it guessed. Use the Playwright MCP server to let an assistant explore a screen and draft a test, then rewrite the assertions. Keep notes on what it got wrong. Week 12 is the README, the cleanup, and practising the walk-through out loud.
Switching from Selenium to Playwright
If you already write Selenium, the move is mostly unlearning. Locators: replace XPath chains with getByRole, getByLabel, getByText and getByTestId. Playwright locators are strict, so a selector that matches two elements fails instead of silently clicking the first. Waits: delete every Thread.sleep and most explicit waits. Actionability checks and web-first assertions such as expect(locator).toBeVisible() retry until they pass or time out. Page objects: same pattern, but the class takes a Page in its constructor and exposes locators as properties. Parallelism: no Grid to stand up, because workers are set in the config. Debugging: run with --trace on and open the trace instead of adding print statements. Give yourself two weeks for the switch and expect your Playwright tests to come out shorter than the Selenium versions.
How to talk about it in interviews
Interviewers hiring a manual tester into an automation role want to know three things: whether you can write code, whether you understand why tests fail, and whether you can work inside a team's existing framework. Answer with specifics from your project. "I automated our checkout regression, 32 cases, in Playwright and TypeScript. It runs in GitHub Actions on every push in about four minutes. The hardest one was a flaky address form, which I fixed by waiting on the network response instead of a timeout." Then open the repository. Know your framework well enough to add a test live if they ask. Be straightforward about what you have not done. A tester who says "I have not used Selenium Grid, but here is how I run tests in parallel in Playwright" gets further than one who bluffs, because the interviewer has usually read the repository before the call.
What to do next
This plan is the self-taught version of NextGen SDET (Playwright), our Playwright course for working testers: two months, live, from TypeScript fundamentals through framework building, AI-assisted testing with Playwright MCP, and CI, ending in a capstone, with placement assistance after. A counsellor can tell you on one call whether the batch or the self-taught route suits your schedule: request a call-back. There is also a free three-hour Playwright + AI masterclass on Zoom, where you fix a failing test with the trace and AI.