QA Automation Roadmap 2026: Essential Skills to Get Hired

Learning Playwright before JavaScript means you'll copy-paste code without understanding why it breaks. The order of these nine skills is deliberate: each one enables the next, and skipping ahead costs more time than it saves. This roadmap covers what to learn in what sequence, with honest time estimates for each stage and guidance on what to skip until you actually need it.

Why the order matters

You can't write real tests without JavaScript. Full stop. And you can't automate an API if nobody ever explained to you what an API actually is. And you definitely can't set up CI/CD when you have zero tests worth running yet.

Each skill here unlocks the next one. Skip around and you'll spend twice as long confused.

1. Playwright: your test automation framework

Selenium used to be the answer. It isn't anymore. Not for new learners in 2026.

Playwright replaced it on most new projects and for reasons that become obvious the moment you actually use both. It auto-waits for elements instead of making you guess sleep timers. Comes with a built-in test runner, video recordings of failures, network interception, and a code generator that writes locators for you while you click around the page.

Here's what a real Playwright test looks like:

import { test, expect } from '@playwright/test';

test('user can log in', async ({ page }) => {
  await page.goto('https://lab.becomeqa.com');
  await page.getByRole('button', { name: 'Login' }).click();
  await page.getByLabel('Username').fill('admin@becomeqa.com');
  await page.getByLabel('Password').fill('testpass123');
  await page.getByRole('button', { name: 'Submit' }).click();

  await expect(page.getByText('My Travel Items')).toBeVisible();
});

Clean. No boilerplate. If none of that makes sense yet, that's fine (the Playwright course covers exactly this).

2. JavaScript/TypeScript: the language layer

Some people try to skip this and go straight to tests. Works for maybe two weeks. Then something breaks and they have absolutely no idea why, because they never learned the language, they just copy-pasted it.

Playwright is JavaScript. TypeScript is JavaScript with types added. The types catch your mistakes before you run anything. Playwright scaffolds TypeScript by default and after a week with it you won't want to go back to plain JS.

What you actually need:

Start with variables, data types, functions, arrays and objects, and async/await. That last one is not optional. Every single Playwright action uses it. Without understanding async/await you're flying blind.

Then, once you're writing tests regularly: destructuring, spread operator, modules, try/catch error handling, and classes for Page Object Model.

Don't wait until you've "finished JavaScript" before touching tests. That's a trap. Learn the essentials, start writing tests, pick up the rest as you need it. The tests give you a concrete reason to use the language.

3. Practice on a real website

Theory without a site to automate is just reading. You need real forms, real tables, real edge cases.

Most practice sites are either trivially simple (one button, one text field) or they go down randomly and give you errors that have nothing to do with your test code. Both are worse than useless for learning.

We built lab.becomeqa.com for this. Full login flow, sortable data tables, modals, file upload, a payment form wired to Stripe test mode, and API endpoints exposed for direct testing. It's maintained to stay stable because flaky practice environments teach you the wrong debugging habits.

Other decent options if you want alternatives: SauceDemo, The Internet by Dave Haefner, TodoMVC. But lab.becomeqa.com has the API set up to match the exercises in this course.

4. API testing: faster and more stable than UI tests

Most beginners don't know this: the majority of bugs in web apps don't live in the UI. They live in the API, the backend logic the UI is calling.

UI tests take seconds. API tests take milliseconds. And API tests don't break because a button shifted two pixels to the left or a loading spinner took slightly longer than expected. They're more stable, faster to write, and catch a class of bugs that UI tests simply never reach.

Playwright has API testing built in through the request fixture:

test('GET /api/items returns a list', async ({ request }) => {
  const response = await request.get('https://lab.becomeqa.com/api/items');

  expect(response.status()).toBe(200);

  const items = await response.json();
  expect(items.length).toBeGreaterThan(0);
  expect(items[0]).toHaveProperty('destination');
});

No browser. No page. Just HTTP. Tools worth knowing: the request fixture (already built into Playwright), Postman for manual API exploration, and basic HTTP methods (covered in skill 7).

5. CI/CD: make your tests actually useful

Tests that only run on your laptop don't catch production bugs. They catch bugs after you happen to run them manually. That's not automation, that's just delayed manual testing.

CI/CD pipelines run your tests on every commit, every PR, every deployment. Automatically. Here's how the main tools differ in practice:

Get your Playwright tests into GitHub Actions first. You can do it in a day.

6. SQL basics: check the database yourself

At some point you'll need to verify that what the UI shows actually got saved to the database. Or look at data the UI never exposes. That requires SQL.

Good news: QA SQL is not complex SQL. It's maybe five query patterns that cover 80% of what you'll ever need:

-- Check if a user exists
SELECT * FROM users WHERE email = 'test@example.com';

-- Check related data across tables
SELECT orders.id, users.email, orders.status
FROM orders
JOIN users ON orders.user_id = users.id
WHERE orders.status = 'pending';

Two SELECT statements. One JOIN. WHERE conditions. That's genuinely most of it. Roles that ask for "SQL experience" are almost always asking for exactly this and not much more.

7. How the internet works

Every test you write is sending requests across a network. Understanding what happens underneath helps you read error messages properly, narrow down what broke, and follow what developers are describing when something goes wrong.

Type https://lab.becomeqa.com in a browser and four things happen in sequence:

• DNS lookup. Browser asks "what's the IP for lab.becomeqa.com?" Gets back something like 104.21.8.42. Domain names are just aliases.
• TCP connection. Browser connects to that IP on port 443, which is the standard HTTPS port.
• TLS handshake. Browser and server verify identities and negotiate encryption. This is the S in HTTPS.
• HTTP request/response. Browser sends GET / HTTP/1.1, server sends back HTML.

Sub-100ms on a decent connection.

"Connection refused" is a different problem than "SSL certificate error" which is a different problem than "404 Not Found." Three different points in that chain. If you don't know the chain, every network error looks the same to you and debugging takes five times longer.

HTTP basics: requests have a method (GET reads, POST creates, PUT/PATCH updates, DELETE removes), a path, headers, and optionally a body. Responses have status codes: 200 is fine, 404 is path not found, 500 means the server itself crashed. Every click and form submit in a Playwright test is one of these requests happening under the hood.

8. Git basics

Git is how test code gets shared, versioned, and deployed. You use it to store your tests, stay in sync with developers, and trigger CI runs. You don't need to understand git internals. Six commands and one config file is the whole job.

git clone <repo-url>            # download the project to your machine
git pull                        # get the latest changes from your team
git checkout -b add-login-tests # create a branch for your new tests
git add tests/login.spec.ts     # stage the file you changed
git commit -m "add login tests" # save a snapshot with a message
git push origin add-login-tests # upload your branch to GitHub/GitLab

Clone once. Pull before starting each day. Branch per feature. Push when done. That's the loop.

Playwright generates folders full of screenshots, videos, and HTML reports when tests run. None of that belongs in the repository. Create .gitignore in the project root:

node_modules/
playwright-report/
test-results/
.env

Skip this file and you'll push hundreds of megabytes of test artifacts. Your teammates will find out who did it.

Tests pass locally but fail in GitHub Actions. Very common. First thing to check:

git log --oneline -5     # see the last 5 commits
git diff main            # see what changed vs. the main branch

Usually it's either a file you forgot to git add, or a dependency version that differs between your machine and the CI environment. Git log shows exactly what was committed and what wasn't.

9. Agile/Scrum: speak the team's language

Easiest skill on the list. Most overlooked by career-changers. You don't need a certification. You need to not look confused in your own standup.

What actually matters: what a sprint is (two-week work cycles, usually), how standups work (what did you do, what are you doing today, anything blocking you), what a user story is, and what "definition of done" means from a QA perspective specifically, because it's different from what a developer means when they say it.

Most teams use Jira. The specific tool changes company to company. The concepts don't.

How long does this realistically take?

Honest answer: four to six months of 1–2 hours per day gets most people to entry-level job-ready. That assumes you're actually practicing, not just reading.

People who take longer almost always have the same pattern: two weeks of intense practice, then nothing for six weeks. Consistency beats intensity. A boring hour every day beats a heroic weekend every month.

FAQ

No. Most QA automation engineers don't have CS degrees. What gets you hired is a GitHub repo with well-written tests and the ability to talk through what they do. A degree doesn't prove that. Tests do.

Playwright for anyone starting from scratch in 2026. If you're joining a company already using Selenium, learn their setup. For fresh learning, Playwright is faster to pick up, better documented, and actually maintained by a team that cares about it.

Manageable. You're not building apps. You're reading and writing tests. That's a narrow slice of the language. Most people get comfortable enough in four to six weeks of daily practice.

lab.becomeqa.com, a GitHub repo with your test files, automating flows on public websites. A portfolio you can walk through on a screen share during an interview is worth more than any certification that exists.