How to Become a QA Engineer in 2026: The Full Roadmap (No Degree Required)

Most beginners waste months on abstract programming exercises before writing a single test. The better path is Playwright first: write a real test against a real website on day one, and use the language confusion you hit along the way as the signal for what to study next. This guide covers the exact skills junior job postings require in 2026, the right order to learn them, and what a portfolio needs to contain to pass a technical screening.

The role has two flavors and you need to pick one early

When most people say "QA engineer" they mean one of two different jobs. Manual QA testers explore software by hand, write test cases, report bugs, and communicate findings to developers and product managers. Automation QA engineers write code that tests software automatically, running checks on every deployment without a human clicking through anything.

Manual is easier to enter. Automation pays significantly more and has better long-term career trajectory. The median salary for a QA automation engineer in the US is $95,000–$115,000 depending on location and company size. Manual QA roles typically sit $20,000–$30,000 lower.

This guide covers the automation path, because that's where the market is heading and where the compound career growth is. If you're starting from zero, that is the path worth taking.

The good news: you don't need a computer science degree for either role. Dozens of working QA automation engineers started as teachers, customer service reps, project managers, and accountants. The technical skills are learnable. What you're actually selling in a job interview is proof that you learned them.

The only technical skills that actually matter for a first job

Job postings for junior QA automation roles in 2026 cluster around the same short list. If you see a posting asking for 15 specific skills, most of them are aspirational. What actually gets you through the technical screen is this:

Playwright or Selenium (Playwright strongly preferred for anyone starting now), JavaScript or TypeScript (TypeScript is what most modern projects use), basic API testing, Git, and some understanding of how CI works. That's it. Everything else is nice-to-have that you pick up on the job.

Here's a real-world example of what a junior QA automation engineer does on day one. You clone a test repository, run the existing test suite, watch some tests pass and a few fail, and your first task is to figure out why the failing ones are failing. That requires Git to get the code, Node.js to run it, TypeScript to read it, and Playwright to understand the errors. Nothing else. No certification, no 30-skill checklist.

Start with Playwright before anything else

This is the counterintuitive part of the roadmap. Most people start with "learning programming" because that's what career guides tell them. The problem with that approach is that pure programming exercises are abstract and get boring fast. You'll spend weeks on fizzbuzz problems and array manipulation while the actual reason you wanted to learn (breaking and testing software) stays permanently in the future.

Start with Playwright first. Accept that you'll copy-paste code you don't fully understand. Run it. See it work. Break it deliberately. See what error comes back.

Here's the actual first test worth writing, using lab.becomeqa.com:

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

test('login with valid credentials', 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();
});

Run this. Watch it open a browser, fill in fields, and click buttons without you touching anything. That feeling of watching automation work for the first time is what keeps people going through the harder parts.

Then write a second test that uses wrong credentials and asserts the error message appears. Then write a third that logs out and verifies the page returns to the login state. Three tests, all on real UI, and you've already practiced locators, assertions, and test structure.

JavaScript and TypeScript: learn just enough, then keep going

Once you're writing tests, you'll hit language walls. You'll see async and await and not know what they mean. You'll want to store a value from one test step and use it in another and not know how variables work across await calls. These are the moments to stop and learn the language concept that's blocking you.

The minimum JavaScript/TypeScript you need before you can write real tests: variables and const/let, functions, arrays and objects, async/await and why it exists, and basic string operations. That's roughly two to three weeks of daily practice if you've never written code before.

The concepts you'll pick up as you write more tests: TypeScript types and interfaces, destructuring assignment, modules and imports, and classes when you get to Page Object Model.

A concrete example of how async/await trips people up early on. If you write this:

const text = page.getByText('Welcome').textContent();
console.log(text); // logs a Promise, not the text

You get a Promise object printed to the console, not the actual text. The correct version is:

const text = await page.getByText('Welcome').textContent();
console.log(text); // logs 'Welcome'

The await tells JavaScript: stop here, wait for this async operation to finish, then give me the result. Every Playwright action uses await. Understanding why makes debugging ten times faster.

API testing is not optional

Most beginners skip API testing because it feels like a separate, harder skill. It isn't either of those things. An API test is just an HTTP request with assertions on the response. No browser, no clicking, no locators.

Here's why it belongs on your learning list early: API tests are five to ten times faster than UI tests and they fail for fewer unrelated reasons. A UI test can fail because a button moved, a loading spinner took an extra second, or a tooltip covered the element. An API test fails because the data is wrong, which is the thing you actually care about.

Playwright has API testing built into the same framework you're already using:

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

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

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

No new tools. No separate framework. The same test and expect functions you already know, with request instead of page.

Also spend a few hours in Postman. Not because you'll use it for automation, but because manually exploring an API before you write tests for it saves time. You send requests, see the response shapes, understand the auth headers, then your test code makes sense instead of being cargo-culted from documentation.

Build something you can show, not just something you understand

Here's where most self-learners stall. They go through tutorials, write exercises, and feel like they're making progress. Then someone asks "can I see your work?" and there's nothing to share.

Hiring managers look at GitHub profiles for junior QA candidates. Not because they expect polished, senior-level test suites. Because a GitHub repo proves you actually wrote the code and didn't just watch videos about it.

A portfolio that will get you interviews is straightforward: one GitHub repository with a Playwright test suite covering a real website, TypeScript configuration, a Page Object Model for at least two pages, both UI and API tests, and a GitHub Actions workflow that runs the tests on every push. That's it. That's the bar.

The Page Object Model part sounds intimidating before you've done it. Here's the concept: instead of writing page.getByLabel('Username').fill(username) in every test that needs to log in, you create a LoginPage class with a login(username, password) method. Tests call loginPage.login('admin@becomeqa.com', 'testpass123'). If the login form ever changes, you fix it in one place.

// pages/LoginPage.ts
export class LoginPage {
  constructor(private page: Page) {}

  async login(username: string, password: string) {
    await this.page.getByRole('button', { name: 'Login' }).click();
    await this.page.getByLabel('Username').fill(username);
    await this.page.getByLabel('Password').fill(password);
    await this.page.getByRole('button', { name: 'Submit' }).click();
  }
}

Use lab.becomeqa.com as the site you automate for your portfolio. It has enough complexity (login, data tables, modals, file upload, API endpoints) to demonstrate real skills without the site going down or blocking automated traffic.

How to apply this Monday morning

If you're reading this on a Sunday night and want a concrete plan for the next week, here it is.

Monday: Install Node.js and Playwright. Follow the official quickstart. Get one test running against lab.becomeqa.com. Don't move on until you see a green test in your terminal.

Tuesday: Write five more tests. Login success, login failure, navigate to a specific section, check that data loads, and one that uses the API endpoint directly. You'll hit problems. That's the actual practice.

Wednesday: Learn the async/await concept properly. Read the MDN article on Promises. Watch one short video. Come back and read your existing test code again. It should make more sense.

Thursday: Create a GitHub account if you don't have one. Push your test repository. Make the README honest: "Learning Playwright, work in progress" is fine.

Friday: Add a GitHub Actions workflow file. The Playwright docs have a copy-paste example for this. Get your tests running in GitHub Actions. Screenshot the green check mark. Keep it.

Week two: Page Object Model for the login flow. Week three: TypeScript interfaces for your API response data. Week four: apply for one junior QA position even if you don't feel ready. Reading the job posting will tell you exactly what to study next.

The people who get hired don't wait until they feel ready. They build evidence that they can do the work, put it somewhere visible, and start talking to companies while they keep learning.

FAQ

Four to six months of daily practice for most people with no prior programming experience. Less if you're coming from a development background. More if you're only practicing on weekends. The variable isn't talent. It's consistency and the quality of what you build to show.

Not to get hired at most companies today. Playwright has displaced Selenium on the majority of new projects. If a specific company you want to join uses Selenium, you can learn the differences in a week once you know Playwright. The concepts are nearly identical, the syntax differs.

ISTQB Foundation Level is the most recognized certification in QA. It demonstrates familiarity with testing theory and terminology. Some companies filter for it, most don't require it. If you're choosing between getting ISTQB certified and building a portfolio project, build the portfolio project. A GitHub repo with working tests is harder evidence than a multiple-choice exam.

Your GitHub portfolio, specifically. List the project with a link, describe what you built ("Playwright test suite with 40+ tests covering UI flows and REST API endpoints, running in CI via GitHub Actions"), and note the technologies. Recruiters see GitHub links and actually follow them. Put your resume in front of people who will click the link before worrying about how to phrase everything else.

Automation. It pays more, it's where the industry is going, and the learning curve is front-loaded. Once you're through it, you're employable. Starting with manual QA and transitioning to automation later means learning twice. The only exception is if you can get a manual QA job quickly and use it to transition internally at a company that will pay for your development time.