Introduction
Skill lists for QA engineers are long and vague: "automation", "communication", "AI". They rarely say what to learn first, how deep to go, or how to show an employer that you can actually do it.
This roadmap is built differently:
- Order. Skills are listed so each one builds on the ones before it.
- A project for each skill. Every project uses free, public practice sites, so you can start today.
- Proof. Each project produces something you can link to in a portfolio or walk through in an interview.
The projects link to guides on this site, where the examples were run before they were published. To check off steps as you go, use the interactive QA engineer roadmap.
How to use this roadmap
- New to testing: work through skills 1 to 5 in order. Together they cover what junior roles usually ask for.
- Manual tester moving to automation: check that you're solid on 1 to 3, then focus on 4 to 8.
- Automation engineer: skim 1 to 5, and use 6 to 10 to fill gaps.
Keep your projects in one public Git repository with a short README per project. A reviewer who can clone it and run your tests learns more in five minutes than from any list of tools on a CV.
1. Test design
Why it matters: choosing what to test decides whether you find bugs. Automation only repeats the checks you design.
Learn: test case structure, equivalence partitioning, boundary value analysis, and error guessing.
Project: write ten test cases for the checkout information form on Sauce Demo, run them, and record the results. Mark every case whose expected result depends on a requirement nobody wrote down.
Proof: a table of cases with expected and observed results, and a list of open questions.
Guide: How to write effective test cases.
2. Bug reporting
Why it matters: a bug nobody can reproduce doesn't get fixed. Clear reports are the most visible part of a tester's work.
Learn: titles, steps from a known state, expected versus actual, reproducibility, impact, severity versus priority, and evidence.
Project: find a bug on Sauce Demo's problem_user account and write it up. Paste it into our bug report grader and improve it until nothing important is missing.
Proof: the final report and the screenshot or trace you attached.
Guide: How to write high-quality bug reports.
3. Exploratory testing
Why it matters: scripted checks confirm what you expected. Exploration finds what you didn't.
Learn: writing a charter (a mission for a time-boxed session), comparing against a baseline, taking notes as you go, and varying one thing at a time.
Project: a 30-minute session on Sauce Demo using every account on the login page, then compare your notes with the answer key in our beginner's guide.
Proof: your session notes: the charter, what you covered, what you found, and what you'd explore next.
Guide: What is software testing? (includes the exercise).
4. API testing
Why it matters: most business rules live behind APIs. API tests are faster and more stable than UI tests, and some bugs are only visible there.
Learn: HTTP methods and status codes, JSON, authentication, and checking response bodies, not only status codes. Use curl or Postman to explore, and a code framework to automate.
Project: test the public Restful Booker API: create, read, update, and delete a booking, and write down every status code that surprises you.
Proof: a Postman collection that runs with Newman, or the same checks as code, plus your table of observed status codes.
Guide: API testing for beginners.
5. One UI automation framework, properly
Why it matters: browser tests protect the journeys customers use. Knowing one framework well is worth more than knowing a little of three.
Learn: user-facing locators, auto-waiting assertions, fixtures, and reading failure output. Pick the framework your target employers use; if you have no preference, Playwright is a strong default for new projects.
Project: login and checkout tests for Sauce Demo, a login fixture, and one test you break on purpose so you can explain its failure output.
Proof: the repository, with a README that says how to run the tests.
Guides: Playwright tutorial, Selenium WebDriver in Java, and Cypress vs Playwright vs Selenium.
6. Git and continuous integration
Why it matters: tests that only run on your laptop protect nobody. Teams expect tests to run on every pull request.
Learn: branches, commits, and pull requests, and a GitHub Actions workflow that installs dependencies, runs tests, and uploads the report when something fails.
Project: add a workflow to your repository from skill 5 so the tests run on every push. Break a test in a branch and open a pull request to watch the check fail.
Proof: a pull request with a red check that you then fixed.
Guide: Integrating tests into CI/CD.
7. Test data and SQL basics
Why it matters: many "flaky" tests are really data problems, and many bugs are only visible in the database.
Learn: creating unique data per test, cleaning up afterwards, and enough SQL to read and filter records: SELECT, WHERE, JOIN, ORDER BY, and GROUP BY.
Project: a Playwright fixture that creates a Restful Booker booking with a unique name and deletes it after the test, even when the test fails.
Proof: the fixture and two tests that use it, passing when run in parallel and when run twice in a row.
Guide: Test data management for automated tests.
8. Debugging failures
Why it matters: a red build is only useful if someone can explain it quickly. The person who finds out why a test failed is valuable to any team.
Learn: reading assertion output, browser developer tools (network and console), Playwright traces, and telling a product bug from a test bug and an environment problem.
Project: take a failing test, open its trace, and write three sentences: what failed, why, and which of the three kinds of problem it is.
Proof: the write-up, with a screenshot from the trace viewer.
Guides: Flaky tests hide behind retries and UI automation mistakes we reproduced.
9. Accessibility basics
Why it matters: accessibility bugs exclude real users, and in many countries they carry legal risk. Many are easy to find once you know how to look.
Learn: keyboard-only navigation, visible focus, text alternatives for images, form labels, color contrast, and what the WCAG success criteria are.
Project: test one page using only the keyboard, then run an automated scan with axe (the browser extension or @axe-core/playwright) and compare what each approach found.
Proof: a short report listing issues found by hand, issues found by the scan, and which ones only one method caught.
Source: W3C: WCAG 2 overview.
10. Working with AI assistants
Why it matters: AI tools now write, fix, and generate tests. Someone has to judge whether the result still tests the right thing.
Learn: using an assistant to draft tests and explain errors, then reviewing its output as critically as a colleague's. Does the test still assert the important behavior, or did a "fix" just make it pass?
Project: ask an assistant to write a Sauce Demo checkout test, then review it. Paste it into our Playwright test reviewer, and use compare mode on any version an agent "healed".
Proof: the generated test, your review comments, and the corrected version.
Guide: Playwright test agents: what init-agents sets up.
The skills that make the others count
Two skills don't get their own project because they show up in every one:
- Clear writing. Bug reports, test cases, session notes, and pull request descriptions are all writing. Use short sentences, exact values, and no blame.
- Thinking in risk. "What would hurt customers most if it broke?" decides what to test first, what to automate, and when to stop.
What about certifications?
The ISTQB Certified Tester Foundation Level (CTFL) is a widely recognized entry-level testing certification. It gives you a shared vocabulary, and some employers list it in job adverts. It doesn't show that you can test a real product; the projects above do. If a role you want asks for it, take it alongside the projects, not instead of them.
Conclusion
Learn the skills in order, and prove each one with a small, public project: a test case table, a bug report, session notes, an API collection, a tested repository with CI, a data fixture, a failure write-up, an accessibility report, and a reviewed AI-generated test. Ten projects on free practice sites make a stronger case than any list of tools on a CV.