QA Engineer Roadmap 2025 (Step-by-Step Guide)

Quality Assurance engineering is one of the most stable and consistently in-demand roles in tech. Every software team needs QA, yet it's far less crowded than software engineering. This roadmap shows you exactly what to learn, in what order — from zero manual tester to automation engineer with a full CI/CD pipeline, in 9–12 months.

At a glance

Phase 1 — Testing fundamentals and SDLC

Before you write a single test, you need to understand what testing is for and where it fits in the software development lifecycle.

SDLC models

Test types hierarchy

E2E / UI tests         ← few, slow, expensive (UI layer)
        ↑
Integration tests      ← moderate, test component interaction
        ↑
Unit tests             ← many, fast, cheap (function level)

The Testing Pyramid principle: most tests should be unit tests. Heavy reliance on E2E tests is the most common anti-pattern.

Core vocabulary every QA must know

Bug reporting best practice

A good bug report contains:

1. Title — short, specific ("Login button unresponsive on Safari 17")
2. Environment — OS, browser, app version, device
3. Preconditions — account type, test data needed
4. Steps to reproduce — numbered, exact
5. Expected result — what should happen
6. Actual result — what actually happens
7. Severity/Priority — your assessment
8. Attachments — screenshots, video, logs

Phase 2 — Manual testing skills

Automation doesn't replace manual testing — it frees your time for the testing only humans can do.

Test design techniques

Test case writing template

ID: TC-LOGIN-001
Title: Valid credentials login
Preconditions: User account exists, email=test@example.com, pass=Test1234!
Steps:
  1. Navigate to /login
  2. Enter email: test@example.com
  3. Enter password: Test1234!
  4. Click "Log in"
Expected: User redirected to /dashboard, username visible in header
Priority: High

What to test beyond the happy path

• Negative tests — invalid inputs, wrong passwords, missing required fields
• Edge cases — empty strings, null, very long inputs, special characters (emoji, SQL)
• Boundary conditions — min/max values, 0, -1, empty arrays
• Concurrency — two users editing the same record simultaneously
• Security basics — XSS in input fields, path traversal, IDOR (object reference)
• Accessibility — keyboard navigation, screen reader labels, colour contrast

Phase 3 — SQL and databases for testers

QA engineers constantly need to verify data in the database — don't rely on the UI alone.

Essential SQL for QA

-- Verify user was created
SELECT id, email, created_at FROM users WHERE email = 'test@example.com';

-- Check order total matches UI
SELECT SUM(price * quantity) as total
FROM order_items WHERE order_id = 12345;

-- Find orphaned records (data integrity check)
SELECT o.id FROM orders o
LEFT JOIN users u ON o.user_id = u.id
WHERE u.id IS NULL;

-- Count records for pagination validation
SELECT COUNT(*) FROM products WHERE category = 'electronics';

-- Verify soft-delete logic
SELECT id, deleted_at FROM posts WHERE id = 99;

Joins testers must know

Test data management

• Use dedicated test databases — never test against production
• Reset test data between test runs for repeatability
• Use factories/fixtures to generate consistent test data
• Be careful with PII — anonymize production dumps

Tools: Faker (Python/JS) generates realistic fake data; DB Fiddle for quick SQL practice.

Phase 4 — API testing

Most modern apps are built on APIs. API testing is faster, more reliable, and finds bugs that UI tests miss.

REST API basics for testers

HTTP status codes you must know

Postman workflow

Collection: User API
├── Folder: Auth
│   ├── POST /auth/register    → save {{token}} to env
│   └── POST /auth/login       → save {{token}} to env
├── Folder: Users
│   ├── GET  /users/me         → verify fields
│   ├── PUT  /users/me         → update + verify
│   └── DELETE /users/me       → 204 + verify gone
└── Folder: Edge cases
    ├── POST /auth/login (wrong password)  → 401
    ├── GET  /users/99999 (missing)        → 404
    └── POST /users (duplicate email)      → 409

Pre-request scripts — set up auth tokens, timestamps, unique emails:

pm.environment.set("unique_email", `test_${Date.now()}@example.com`);

Test scripts — assert responses in Postman:

pm.test("Status is 200", () => pm.response.to.have.status(200));
pm.test("Has user id", () => {
  const body = pm.response.json();
  pm.expect(body.id).to.be.a("number");
  pm.expect(body.email).to.equal(pm.environment.get("test_email"));
});
pm.environment.set("user_id", pm.response.json().id);

Newman — run Postman in CI

# Install
npm install -g newman

# Run collection
newman run my-collection.json -e staging.json --reporters cli,junit --reporter-junit-export results.xml

Phase 5 — Programming basics (Python or JavaScript)

You need one language well enough to write automation. Python is the most popular QA choice; JavaScript if you're testing a JS-heavy app.

Python for QA — the essentials

# String manipulation
url = f"https://api.example.com/users/{user_id}"
assert "error" not in response.text.lower()

# List comprehension
failed_tests = [t for t in results if t["status"] == "failed"]

# File handling — read test data CSV
import csv
with open("test_data.csv") as f:
    users = list(csv.DictReader(f))

# HTTP requests — manual API testing
import requests
response = requests.post(
    "https://api.example.com/auth/login",
    json={"email": "test@example.com", "password": "Test1234!"}
)
assert response.status_code == 200
token = response.json()["token"]

# Environment variables — keep secrets out of code
import os
base_url = os.getenv("API_BASE_URL", "https://staging.example.com")

JavaScript for QA (Node.js)

// Fetch API
const response = await fetch(`${BASE_URL}/users/${userId}`, {
  headers: { Authorization: `Bearer ${token}` }
});
const user = await response.json();
console.assert(user.email === expectedEmail);

// Array methods
const failedCases = results.filter(r => r.status !== "passed");
const emails = users.map(u => u.email);

// Async/await pattern common in Playwright/Cypress
async function login(page, email, password) {
  await page.fill('[name="email"]', email);
  await page.fill('[name="password"]', password);
  await page.click('[type="submit"]');
  await page.waitForURL("**/dashboard");
}

Phase 6 — Selenium WebDriver and automation frameworks

Selenium is the foundation of browser automation. Even if you move to Playwright later, understanding Selenium makes you stronger.

Selenium with Python (pytest)

# conftest.py — shared fixtures
import pytest
from selenium import webdriver
from selenium.webdriver.chrome.options import Options

@pytest.fixture(scope="session")
def driver():
    options = Options()
    options.add_argument("--headless")
    options.add_argument("--no-sandbox")
    driver = webdriver.Chrome(options=options)
    driver.implicitly_wait(10)
    yield driver
    driver.quit()

# test_login.py
from selenium.webdriver.common.by import By

def test_valid_login(driver):
    driver.get("https://example.com/login")
    driver.find_element(By.NAME, "email").send_keys("test@example.com")
    driver.find_element(By.NAME, "password").send_keys("Test1234!")
    driver.find_element(By.CSS_SELECTOR, "[type='submit']").click()
    assert "/dashboard" in driver.current_url

def test_invalid_login_shows_error(driver):
    driver.get("https://example.com/login")
    driver.find_element(By.NAME, "email").send_keys("wrong@example.com")
    driver.find_element(By.NAME, "password").send_keys("wrongpass")
    driver.find_element(By.CSS_SELECTOR, "[type='submit']").click()
    error = driver.find_element(By.CLASS_NAME, "error-message")
    assert "Invalid credentials" in error.text

Locator strategy priority

Page Object Model (POM)

The most important pattern in test automation — keeps tests readable and maintainable.

# pages/login_page.py
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

class LoginPage:
    URL = "/login"

    def __init__(self, driver):
        self.driver = driver
        self.wait = WebDriverWait(driver, 10)

    def open(self, base_url):
        self.driver.get(f"{base_url}{self.URL}")
        return self

    def enter_email(self, email):
        self.driver.find_element(By.NAME, "email").send_keys(email)
        return self

    def enter_password(self, password):
        self.driver.find_element(By.NAME, "password").send_keys(password)
        return self

    def submit(self):
        self.driver.find_element(By.CSS_SELECTOR, "[type='submit']").click()
        return self

    def get_error(self):
        return self.wait.until(
            EC.visibility_of_element_located((By.CLASS_NAME, "error-message"))
        ).text

# tests/test_login.py
def test_valid_login(driver, base_url):
    page = LoginPage(driver).open(base_url)
    page.enter_email("test@example.com").enter_password("Test1234!").submit()
    assert "/dashboard" in driver.current_url

Phase 7 — Modern automation: Playwright and Cypress

Playwright and Cypress have largely replaced Selenium for new projects. They're faster, more reliable, and have better developer experience.

Playwright (Python or TypeScript)

// tests/login.spec.ts
import { test, expect } from "@playwright/test";

test.describe("Login", () => {
  test("valid credentials → redirect to dashboard", async ({ page }) => {
    await page.goto("/login");
    await page.fill('[name="email"]', "test@example.com");
    await page.fill('[name="password"]', "Test1234!");
    await page.click('[type="submit"]');
    await expect(page).toHaveURL(/dashboard/);
  });

  test("invalid password → error message", async ({ page }) => {
    await page.goto("/login");
    await page.fill('[name="email"]', "test@example.com");
    await page.fill('[name="password"]', "wrongpassword");
    await page.click('[type="submit"]');
    await expect(page.locator(".error-message")).toContainText("Invalid");
  });

  test("API-seeded user login", async ({ page, request }) => {
    // Create user via API — faster than UI setup
    const res = await request.post("/api/users", {
      data: { email: `test_${Date.now()}@example.com`, password: "Test1234!" }
    });
    const { email } = await res.json();

    await page.goto("/login");
    await page.fill('[name="email"]', email);
    await page.fill('[name="password"]', "Test1234!");
    await page.click('[type="submit"]');
    await expect(page).toHaveURL(/dashboard/);
  });
});

playwright.config.ts

import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  testDir: "./tests",
  timeout: 30_000,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 4 : undefined,
  reporter: [["html"], ["junit", { outputFile: "results.xml" }]],
  use: {
    baseURL: process.env.BASE_URL ?? "http://localhost:3000",
    trace: "on-first-retry",
    screenshot: "only-on-failure",
    video: "retain-on-failure",
  },
  projects: [
    { name: "chromium", use: { ...devices["Desktop Chrome"] } },
    { name: "firefox", use: { ...devices["Desktop Firefox"] } },
    { name: "webkit", use: { ...devices["Desktop Safari"] } },
    { name: "mobile-chrome", use: { ...devices["Pixel 5"] } },
  ],
});

Playwright vs Cypress at a glance

Phase 8 — Performance and load testing

Find bottlenecks before users do.

k6 — load testing as code

// load-test.js
import http from "k6/http";
import { check, sleep } from "k6";
import { Rate } from "k6/metrics";

const errorRate = new Rate("errors");

export const options = {
  stages: [
    { duration: "30s", target: 20 },   // ramp up to 20 users
    { duration: "1m", target: 20 },    // stay at 20 users
    { duration: "30s", target: 100 },  // spike to 100 users
    { duration: "30s", target: 0 },    // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<500"],  // 95% of requests < 500ms
    errors: ["rate<0.01"],             // error rate < 1%
  },
};

export default function () {
  const res = http.get("https://staging.example.com/api/products");
  const ok = check(res, {
    "status is 200": r => r.status === 200,
    "response time < 500ms": r => r.timings.duration < 500,
  });
  errorRate.add(!ok);
  sleep(1);
}

k6 run load-test.js
k6 run --out json=results.json load-test.js

Key performance metrics

Types of performance tests

Phase 9 — CI/CD integration

Automated tests only deliver value when they run automatically on every change.

GitHub Actions — full QA pipeline

# .github/workflows/qa.yml
name: QA Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:

jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest tests/unit/ --junitxml=unit-results.xml --cov=src --cov-report=xml
      - uses: actions/upload-artifact@v4
        with:
          name: unit-test-results
          path: unit-results.xml

  api-tests:
    runs-on: ubuntu-latest
    needs: unit-tests
    steps:
      - uses: actions/checkout@v4
      - run: pip install requests pytest
      - run: pytest tests/api/ --junitxml=api-results.xml
        env:
          API_BASE_URL: ${{ secrets.STAGING_URL }}
          API_TOKEN: ${{ secrets.STAGING_TOKEN }}

  e2e-tests:
    runs-on: ubuntu-latest
    needs: api-tests
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test --reporter=html
        env:
          BASE_URL: ${{ secrets.STAGING_URL }}
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/

  performance-test:
    runs-on: ubuntu-latest
    needs: e2e-tests
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - run: |
          curl https://github.com/grafana/k6/releases/download/v0.52.0/k6-v0.52.0-linux-amd64.tar.gz -L | tar xvz
          sudo mv k6-*/k6 /usr/local/bin/
      - run: k6 run tests/performance/load-test.js

Test pyramid in CI — timing strategy

Phase 10 — Mobile testing

Mobile apps have unique failure modes: different screen sizes, OS versions, touch gestures, interruptions.

Appium basics

# Mobile web on Android Chrome
from appium import webdriver
from appium.options import UiAutomator2Options

options = UiAutomator2Options()
options.platform_name = "Android"
options.device_name = "emulator-5554"
options.browser_name = "Chrome"

driver = webdriver.Remote("http://localhost:4723", options=options)
driver.get("https://m.example.com/login")
driver.find_element("id", "com.example:id/email").send_keys("test@example.com")
driver.find_element("id", "com.example:id/password").send_keys("Test1234!")
driver.find_element("id", "com.example:id/login_btn").click()

Device farms

Mobile-specific test areas

• Screen sizes — phone, tablet, foldable
• OS versions — always test last 2–3 major versions
• Orientation — portrait and landscape
• Network conditions — 4G, 3G, offline, network switch
• Interruptions — incoming call, low battery warning, notifications
• Permissions — location, camera, contacts denied/granted
• Deep links — open app from URL or push notification

Phase 11 — Certifications

Certifications aren't mandatory, but they demonstrate structured knowledge — especially valuable early in your career.

ISTQB Foundation (CTFL) is the most recognized globally. Start here.

QA career roles and salaries

Full technology map

QA Engineering
├── Manual testing
│   ├── Test design (EP, BVA, decision tables, state transition)
│   ├── Bug reporting (JIRA, Linear, GitHub Issues)
│   └── Exploratory testing
│
├── API testing
│   ├── Postman / Bruno / Insomnia
│   ├── REST + GraphQL + gRPC
│   └── Newman (CI runner)
│
├── UI Automation
│   ├── Selenium WebDriver
│   ├── Playwright (cross-browser, multi-lang)
│   └── Cypress (JS-native, great DX)
│
├── Mobile testing
│   ├── Appium
│   ├── Detox (React Native)
│   └── XCUITest / Espresso (native)
│
├── Performance testing
│   ├── k6
│   ├── JMeter
│   └── Locust (Python)
│
├── CI/CD
│   ├── GitHub Actions
│   ├── Jenkins
│   └── GitLab CI
│
└── Supporting skills
    ├── SQL (data verification)
    ├── Linux / command line
    ├── Docker (test environments)
    └── Git (version control)

Realistic 12-month timeline

Portfolio project idea

Build a full test suite for an open-source app (like Conduit or OpenCart demo):

qa-portfolio/
├── README.md                # What you tested, tech stack, how to run
├── test-plan.md             # Scope, approach, entry/exit criteria
├── manual/
│   └── test-cases.xlsx      # Or test-cases.md — 30+ manual test cases
├── api/
│   ├── postman/
│   │   └── collection.json  # Exported Postman collection
│   └── tests/
│       └── test_api.py      # pytest + requests
├── ui/
│   ├── pages/               # Page Object Model classes
│   └── tests/               # Playwright or Selenium tests
├── performance/
│   └── load-test.js         # k6 script
└── .github/
    └── workflows/
        └── qa.yml           # CI pipeline that runs all tests

Common mistakes QA beginners make

Frequently asked questions

Do I need to code to become a QA engineer? Not for manual testing, but automation engineering (where salaries are 30–50% higher) requires programming. Python or JavaScript is enough.

Is manual testing dead? No. Exploratory testing, usability assessment, accessibility review, and edge-case discovery still require human judgment. Automation handles repetitive regression; humans handle creative testing.

Selenium vs Playwright — which should I learn first? Playwright if you're starting from scratch in 2025. It's the modern standard. Learning Selenium is still valuable if your job uses it, but Playwright wins in new projects.

How long to get my first QA job? 6–9 months for manual QA. 9–12 months for automation roles. Start applying around month 8 — the job search itself takes time.

ISTQB — is it worth it? Yes, especially for the Foundation level. It provides a universal vocabulary, is recognized globally, and signals commitment. Cost is ~$200, and you can pass with 2–3 weeks of study.

QA vs SDET — what's the difference? QA Engineer focuses on testing strategy, test cases, and automation of test scenarios. SDET (Software Dev Engineer in Test) writes test infrastructure, frameworks, and tools — closer to a software engineer role. SDETs usually earn 15–25% more.