From manual tester to automation engineer: a realistic 45-day roadmap

Every week I get the same message from manual testers: "I have 3–7 years of experience, but every job posting wants automation. Where do I start?" The honest answer is that you don't need six months, a computer science degree, or a 60-hour video course you'll never finish. You need a sequence, 45 minutes a day, and the discipline to write code every single day — including the days you don't feel like it.

This is the roadmap I teach in my live batches, compressed into an article. It assumes zero programming background. If you already know some JavaScript, you can shave a week off the middle.

Why 45 minutes a day beats weekend marathons

Most people plan to learn automation on weekends. It rarely works, and the reason is simple: programming skill is built by frequent retrieval, not long exposure. Six hours on Sunday followed by six days of nothing means every Sunday starts with re-learning last Sunday. Forty-five focused minutes daily keeps the syntax, the patterns and the muscle memory warm — and it fits around a full-time testing job.

The other advantage: a small daily slot forces you to stop while you still know what comes next. You start the next session with momentum instead of a blank page.

Days 1–2: setup, and the mental shift

Install Node.js, VS Code and Git, create a GitHub account, and run your first npx playwright test on the sample project. That's the easy half. The harder half is a mindset change: from now on, you are not "a manual tester learning a tool". You are a developer whose product is test code. Developers version everything, so from day one, every line you write goes into a Git repository. That repo becomes your portfolio, and portfolios beat certificates in every interview I've ever conducted.

Days 3–14: the language, not the framework

This is where most self-learners go wrong — they jump straight to the automation tool and copy-paste code they can't read. Then the first time a test fails with a TypeError, they're stuck. Spend two weeks on JavaScript and TypeScript fundamentals, in this order:

• Variables, types, functions and objects — the vocabulary of every test you'll ever write.
• Arrays and their methods — map, filter, find; test data lives in arrays.
• Async/await — non-negotiable. Every Playwright action is asynchronous, and 80% of beginner bugs are a missing await.
• TypeScript basics — types, interfaces and why the compiler catching your typo at 2 pm beats the CI pipeline catching it at 2 am.

You do not need closures-and-prototypes mastery to start automating. You need to be able to read an error message and know which line to fix.

Days 15–23: Playwright core

Now the framework earns its place. Learn the test runner, fixtures like page, and then give locators the respect they deserve. Prefer user-facing locators — getByRole, getByLabel, getByText — over brittle CSS and XPath. A test that finds the button the way a user finds it survives redesigns; a test wired to div:nth-child(4) > span does not.

Use codegen to record flows, but treat the recording as a first draft you refactor, never as finished code. By day 23 you should be automating logins, forms, dropdowns, file uploads and alerts on a practice site.

Days 24–32: debugging and reliability — the professional gap

Anyone can write a test that passes once. The skill gap between "did a course" and "employable" is what you do when it fails. Learn the Trace Viewer until reading a trace feels like reading a story: what the page looked like, what the test clicked, what the network returned. Then attack flakiness deliberately — auto-waiting, web-first assertions, proper isolation with fresh contexts — and run your suite cross-browser and in parallel.

Interviewers rarely ask "can you write a test?" They ask "a test fails only in CI at 3 am — walk me through what you do." Days 24–32 are your answer.

Days 33–40: framework thinking

Individual specs don't scale; structure does. Introduce Page Object Model, extract test data into fixtures and parameterised loops, and add API testing with Playwright's request context — seeding data through the API and asserting through the UI is the pattern real product teams use to keep suites fast. By day 40 your repository should look like something a team could actually adopt: clear folders, a config for multiple environments, an HTML report.

Days 41–45: AI, CI/CD and graduation

Wire the suite into GitHub Actions so every push runs your tests, then add the modern layer: AI agents and Playwright MCP. Let an agent explore your practice app and draft specs, then review its output like a senior reviews a junior's pull request. Knowing how to direct and verify AI-generated tests is quickly becoming the differentiator in interviews — teams don't need someone who fears the tools their developers already use.

What to skip (for now)

• Multiple frameworks at once. Playwright or Selenium — pick one, get employed, learn the other later.
• Mobile automation. A common trap that doubles the learning surface before the fundamentals are solid.
• Chasing every AI tool on LinkedIn. One agent workflow, understood deeply, beats ten demos you can't reproduce.

The interview at the end

After day 45 you'll have a Git history with 40+ days of commits, a framework repo, and a CI badge. Put the repo link at the top of your resume. When the interviewer asks about your experience, don't recite the syllabus — open the trace of a failing test and debug it in front of them. That's the moment manual-tester resumes turn into automation-engineer offers.