From manual to automation: a practical transition guide

Pick one language and stick with it

The single biggest mistake I see from people transitioning into automation is switching languages mid-journey. They start JavaScript, hear that Python is more popular for automation, switch to Python, hear that Java is what the big enterprise shops use, and six months in they know a bit of everything and can ship nothing.

Pick JavaScript. Here's why.

The web testing ecosystem runs on JavaScript. Cypress is JavaScript. Playwright's best-supported language is TypeScript (which compiles to JavaScript). Most of the tutorials, Stack Overflow answers, and GitHub repos you'll reference are JavaScript. The job postings for mid-level automation engineers in 2026 ask for Cypress or Playwright, both of which assume JavaScript competence.

Python is a legitimate second choice, especially if you're going into API automation or your target employers run Python-heavy stacks. But if you don't already have a reason to pick Python, the ROI on JavaScript is higher for web UI automation.

Java is for enterprise shops that decided on Selenium five years ago and haven't moved. There are jobs there, but fewer of them and they're harder to break into without existing Java experience.

Learn the language before the tool

Three to four weeks, no Cypress, no Playwright, no automation tools at all.

You need to understand variables, functions, callbacks, promises, and async/await. Everything in Cypress is asynchronous. Everything in Playwright is async/await. If you don't understand why const result = cy.get('.button') doesn't return the button element directly, you'll be fighting Cypress instead of using it.

Resources that actually work:

• javascript.info — free, comprehensive, no fluff. Work through the first three sections (The JavaScript Language, Browser: Document Events Interfaces, Additional Articles). Skip the browser section if you want to move faster; come back to it later.
• Exercism.io JavaScript track — free, mentor-reviewed exercises. Do twenty exercises. The muscle memory of writing functions and handling arrays matters more than reading about it.

Don't pay for a bootcamp at this stage. The free resources are better.

Build something boring twice

When you have basic JavaScript, build an automation script for a login form. Then build it again.

The first time, build it with raw Playwright (or Cypress — pick one and start). It'll be awkward. You'll look things up constantly. You'll probably have a bug where the test passes even when it shouldn't. Fix it.

The second time, build it better. Extract the selectors into variables. Add an assertion that checks you actually ended up on the dashboard. Handle the case where the login fails by checking for an error message.

Then build a search test. Type a query into a search box, submit it, verify that results appear and that they contain text related to the query.

That's it. Two features, done twice each. The goal is muscle memory, not portfolio material. You're building the habit of: find element → interact → assert → fix when it's wrong.

The first real portfolio project

After two boring exercises, you need one real project you can point to. Use SauceDemo (saucedemo.com) — it's a demo e-commerce site designed specifically for practice automation. It has login, product listings, a shopping cart, and a checkout flow. It's stable, free, and your automated tests won't break because the site changed.

Build a test suite that covers:

1. Successful login and logout
2. Adding a product to the cart
3. The full checkout flow (product → cart → checkout info → confirmation)
4. Locked-out user sees an error message
5. Sorting products by price (low to high) produces the correct order

Put this on GitHub. Write a README that explains how to run it. Include a CI configuration (GitHub Actions is free) so there's a green badge on the repo.

This project demonstrates: you can write real tests, you understand assertions, you know how to handle data (the user credentials), and you care enough to set up CI.

The job application that gets the interview

What to include on a CV:

• A skills section that lists the specific tools: Cypress / Playwright, TypeScript, GitHub Actions. Not "automation testing" in the abstract.
• The SauceDemo project with a GitHub link. Interviewers look at this.
• Any manual testing experience reframed around what you were actually testing: "Wrote and executed test cases for a payment flow, identified 12 defects before release." Specific numbers, specific features.

What to leave off:

• Tools you've read about but haven't shipped tests in. If someone asks you about Selenium in the interview and you've only read the docs, that's a problem.
• "Quick learner" and "team player" — every CV says this, it means nothing.
• A long education section if you're more than two years out of school. Interviewers want to see what you've built.

The interviews you can realistically land with this background are junior automation engineer roles and "QA engineer who can also do automation" roles at small-to-mid companies. The big enterprise automation roles want more. That's okay — you're building the foundation.

A realistic 6-month timeline

The applications start at week eleven, not week one. The most common mistake is applying before you have anything to show. Interviewers ask "can you show me some code you've written?" very early. Have an answer ready.

Month six isn't guaranteed — some people land something at month four, some at month nine. The timeline assumes focused weekly effort of roughly ten hours. If you have more time, compress it. If you have less, extend it. The order matters more than the duration.