Skip to content
Independent guides for QA & test automationRSSEditorial policy
QA Vibes

Learning path

QA engineer roadmap

6 stages and 25 steps, from testing basics to CI pipelines and AI agents. Check off each step as you finish it.

  • Learn from tested guides

    Every step links to a guide on this site whose examples we ran before publishing.

  • Practice on real targets

    Tasks use free practice sites such as Sauce Demo and Restful Booker, so you can start today.

  • Know when you're done

    Each step ends with a concrete check. Your progress is saved in this browser only: no account, nothing sent to us.

0 of 21 core steps done

  1. 01Understand what testing is for

    0/4

    Before any tool: what testing can tell you, how to explore, and how to choose inputs that find bugs.

  2. 02Report what you find

    0/3

    Findings only matter when someone can act on them, and when the team spends testing time well.

    • A bug nobody can reproduce doesn't get fixed. Clear reports are the most visible part of a tester's work.

      Practice
      Reproduce the problem_user checkout bug on Sauce Demo, write it up, and grade your report.
      Done when
      Your report scores 80 or more in the grader.

    • Acceptance criteria say whether this story does the right thing. A definition of done says whether any work is fit to ship at all.

      Practice
      Write your team's definition of done in seven lines or fewer, then mark which lines a pipeline already enforces and which rely on someone remembering.
      Done when
      Every line is checkable, and for each one you can point at what fails when it is skipped.

    • Automation repeats known checks cheaply; people notice what nobody specified. Good teams decide deliberately.

      Practice
      List ten checks from a project you know and mark each: automate, keep manual, or drop, with a one-line reason.
      Done when
      You can name one bug only exploring would find, and one only automation would catch reliably.

  3. 03Test below the UI

    0/5

    APIs, data, and test layers: where tests are fastest, most stable, and closest to the business rules.

    • Most business rules live behind APIs, and API tests are faster and less flaky than browser tests.

      Practice
      Send Restful Booker's create, update, and delete requests by hand, then save them as a Postman collection and run it with Newman.
      Done when
      Newman exits with code 0, and with code 1 when you pass a wrong password.

    • Some bugs never reach a screen. An order item with no order, or a total that doesn't match its items, only shows up when you query the data.

      Practice
      Solve all six checks in the SQL lab, including the two the guide leaves for you.
      Done when
      Every check returns nothing on the clean copy and exactly the bad rows on both copies with seeded bugs.

    • Shared, leftover data is a common cause of tests that pass on one machine and fail on another.

      Practice
      Write a fixture that creates a booking with a unique name and deletes it after the test, even when the test fails.
      Done when
      Your tests pass when run in parallel and when run twice in a row.

    • A feature that works for one user can still slow down for a hundred. Load tests show where response times break down before customers do.

      Practice
      Run the article's shop API on your own machine and find how many users it handles before checkout's 95th percentile passes 200 ms.
      Done when
      Your load test exits with a non-zero code when a threshold fails, and you can explain the limit you found from the pool size and query time.

    • The cheapest test that can catch a bug is usually the best one.

      Practice
      Take three bugs from a project you know and name the lowest test layer that could have caught each.
      Done when
      You can explain in one sentence why your suite has the shape it has.

  4. 04Automate the browser

    0/5

    One framework learned properly, the mistakes that make suites untrustworthy, and alternatives if your team needs them.

    • Browser tests protect the journeys customers use. Learn one framework well before comparing others.

      Practice
      Build the Sauce Demo login and checkout tests, then change one expected value and read the failure.
      Done when
      From the failure output alone, you can tell whether the element was missing or the value was wrong.

    • The dangerous tests are the ones that pass while checking nothing.

      Practice
      Paste your own tests into the Playwright test reviewer and fix every high-severity finding.
      Done when
      Your tests have no fixed waits, no missing awaits, and no assertions that can never fail.

    • Teams pick tools for language, browsers, and maintenance, not popularity.

      Practice
      Write the add-to-cart test in a second framework and time both runs on your machine.
      Done when
      You can say which framework fits a given team and why.
    • Optional

      Many established teams run Selenium suites in Java, C#, or Python.

      Practice
      Build the Maven login project with a page object and run it with mvn test.
      Done when
      Both tests pass headless, and the browser always quits, even when a test fails.
    • Optional

      Useful when product owners help write and review the scenarios.

      Practice
      Write a feature with one Scenario and one Scenario Outline and run it on the JUnit Platform.
      Done when
      Someone who doesn't read Java can review your feature file.

  5. 05Run tests on every change

    0/4

    Tests protect a product only when they run automatically, stay trustworthy, and can't be used to attack the pipeline.

    • Tests that only run on a laptop protect nobody.

      Practice
      Add a GitHub Actions workflow to your practice project and open a pull request with a failing test. On Azure DevOps, check your publish step with the results checker.
      Done when
      The pull request shows a red check, and the uploaded report explains why. The failing tests appear in the run, not only in the log.

    • Retries keep builds green while hiding real problems in the product or the test.

      Practice
      Pick a test that sometimes fails, measure how often, and use the calculator to decide how many clean runs prove your fix.
      Done when
      Every quarantined test has an owner, an issue, and an expiry date.

    • A pipeline produces evidence. Someone still has to decide whether it is enough to ship, and be able to say no.

      Practice
      Write the go/no-go criteria for your next release, with a threshold on each, before the build exists.
      Done when
      Each criterion could fail on real numbers, and one named person owns the decision and the record of it.

    • Test pipelines install hundreds of packages and hold tokens, which makes them a target.

      Practice
      Find which of your dependencies run install scripts, and set least-privilege permissions in your workflow.
      Done when
      Your test workflow's token can only read the repository.

  6. 06Go further

    0/4

    Accessibility, visual checks, AI agents, and choosing tools: the skills that set experienced testers apart.

Steps marked Optional are alternatives or specializations; skip them if your team doesn't need them. Prefer reading to checking boxes? The same path is written out, with a portfolio project for each skill, in the QA engineer skills roadmap.