New: Roadmaps ordered paths through our cheat sheets and flashcards, so you always know what to study next.
Explore themSee what's new on GitHubFrom your first bug report to a test suite that runs itself.
A 15-step learning path. Follow it in order, or jump to what you need.
For anyone moving into quality assurance, whether starting from zero or already testing by hand and ready to add automation. Plan on about 6 to 10 weeks at a few hours a week, moving from test case design and bug reports through browser and API automation to tests that run themselves on every commit. This path stays on the testing side of the pipeline: it treats CI/CD as just enough to wire a suite in, not full pipeline and infrastructure ownership (see the DevOps Engineer path for that), and covers security only as far as it shows up inside an API test. By the end you can design a test case that actually proves something, automate a browser and API workflow with Selenium and pytest, and wire that suite into a CI pipeline that blocks a bad merge before it ships.
Expected: no formal background, though comfort using a computer and reading documentation carefully helps from day one. Helpful but not required: prior exposure to Python or JavaScript syntax before you reach the automation steps.
Every step from here assumes you know which SDLC phase a feature is in and what 'done' means at that gate, which is why the path opens on the map instead of a tool.
Turning 'I clicked around and it seemed fine' into a boundary-value or equivalence-partition test case is the shift that trips up almost every new tester, and step 8's API tests lean on the same design thinking; expect to revisit it after your first few real bugs.
Files the bugs step 2's test cases actually find: Jira's workflow states and required fields are what make a defect impossible for a developer to wave off.
You can tell a product manager which SDLC phase a feature is in, design a test case that actually proves something, and file a bug a developer can't ignore. Next up: teaching a computer to run this testing for you.
Finish this section to unlock.
+100 XP
Automated scripts from step 5 onward are code, and code needs a home; branches and pull requests are how your suite grows without one broken test blocking everyone else's work.
Controlling a real browser from code instead of clicking through it by hand is where automation stops feeling abstract; locators and waits cause more flaky-test headaches than anything else in this path, and that struggle is normal.
One script from step 5 proves a browser can be driven by code; pytest turns a folder of those scripts into a suite you can run, filter, and trust on every commit.
Before automating the API check in step 8, explore it by hand here: Postman is where you learn what an endpoint actually returns.
Goes past the manual exploring from step 7 into unit, integration, and contract tests for the same endpoints, so a broken API fails your suite before a user ever sees it.
You can write a real Selenium browser test and an automated API check that catches a broken contract before a user does, and a few minutes of due flashcards keeps your test-case and Jira habits from chapter one fresh while you build on them here. Next up: wiring this suite into a pipeline that runs it on every commit.
Finish this section to unlock.
+100 XP
The browser and API suites from steps 5 through 8 only protect the team if they run themselves; wiring them into a workflow means every pull request from step 4 gets tested before it merges.
Gherkin's Given-When-Then turns the test cases from step 2 into scenarios a product owner can read and agree with before a line of step 5's automation gets written.
Individual checks from step 8 can all pass while the real handoff between two services still breaks; these patterns close that gap by testing the seams, not just the parts.
Reach for this if your next role leans toward a modern JS-heavy stack: Playwright's auto-waiting fixes the exact flakiness that step 5's manual Selenium waits made you fight.
Pick this up if your team ships a mobile app: Appium reuses the same locator-and-wait thinking from step 5 and step 12, aimed at native screens instead of a browser DOM.
Choose this track if you want to own the question of what happens under heavy load: load-testing methodology, JMeter and k6, and the p95 and p99 numbers that turn the response times buried in step 8's API tests into a discipline of their own.
Every practice in this path, manual design, browser and API automation, BDD scenarios, only earns its keep once it runs on every commit instead of once before a release; that habit is what this path closes on.
You went from a clean bug report to a browser-and-API suite wired into CI, running BDD scenarios and integration checks that catch what a single test misses. That's the QA Automation Engineer badge, earned: quality is now something your pipeline does automatically, not something you check once at the end.
Finish this section to unlock.
+100 XP
Finish every required step, at least 70% of them genuinely done (not skipped), to earn this badge and 500 XP.