Start here
Your QA learning roadmap, step by step
Manual testing first, then APIs, automation and performance, with career prep whenever you need it. Each step lists what to learn, how to tell you are ready to move on, and free sites to practise on.
Where are you right now?
Pick the line that sounds like you. You can skip what you already know, but be honest about the gaps.
- New to testing You are a student, a fresher or switching careers. Go in order, one step at a time. Start at Step 1
- Already testing manually Tick the Step 1 topics you know well, fill any gaps, then move on to APIs. Start at Step 2
- Already writing automated tests Check the Step 3 list for gaps, then learn how systems behave under load. Go to Step 4
- Interview coming up You do not need to finish Steps 1 to 4 first. Prepare your story and revise the questions. Go to Step 5
Step 1
Manual testing
Every other kind of testing builds on this one. You cannot automate a check that you could not design by hand.
What to learn
- How to write a test case that another person can run without asking you anything
- Test design techniques: equivalence partitioning, boundary value analysis and decision tables
- How to write a bug report: steps to reproduce, expected result, actual result and evidence
- The difference between severity and priority
- Smoke, sanity, regression and exploratory testing, and when each is used
- Where testing fits in the software development life cycle (SDLC) and the software testing life cycle (STLC)
- Agile and Scrum basics: sprints, stand-ups and where a tester fits in the team
Common mistake: testing only the happy path. Most bugs hide in empty fields, very long text, special characters and a button clicked twice.
Exit criteria
Move to Step 2 when:
- You can take a feature you have never seen, such as a login form, and write test cases for valid, invalid and boundary inputs.
- A developer can reproduce a bug from your report without asking you a question.
Practise this step
Interview Prep questions
Free practice sites
- SauceDemoA small online shop. Log in as standard_user, then as problem_user, and write a bug report for everything that looks wrong.
- ParaBankA demo bank. Write test cases for register, transfer funds and bill pay, then run them and note what fails.
Guides for this step
Step 2
API testing
Most applications get their data from a server through an API. Testing the API directly is faster than testing through the screen, and it finds problems the screen hides.
What to learn
- HTTP basics: methods (GET, POST, PUT, PATCH, DELETE), headers and status codes
- How to read and write JSON
- Sending requests in Postman and saving them in collections
- Authentication: API keys, bearer tokens and the basics of OAuth 2.0
- What to check in a response: status code, body, data types and response time
- Negative tests: missing fields, wrong data types and requests without permission
- Basic SQL: SELECT, WHERE, JOIN and GROUP BY, so you can check the data behind the screen
Common mistake: checking only the status code. A 200 OK with the wrong price or a missing field in the body is still a bug.
Exit criteria
Move to Step 3 when:
- You can test an endpoint from its documentation alone, with no screen in front of you.
- You can say what a 400, 401, 403, 404 or 500 response tells you about where the problem is.
Practise this step
Free practice sites
- Restful BookerA hotel booking API with a login token. It has bugs on purpose, so read its docs and go looking for them.
- JSONPlaceholderA free fake API for your first GET, POST, PUT and DELETE in Postman. Nothing is really saved, so check what the response says.
- SQLZooShort SQL exercises that run in the browser, from a simple SELECT up to JOIN.
Guides for this step
Step 3
Automation
Automation runs the checks you would otherwise repeat by hand on every release. It only pays off when the test behind it is well designed, which is why it comes after Steps 1 and 2.
What to learn
- One programming language to a working level: JavaScript or TypeScript, Python, or Java
- Git basics: clone, branch, commit and pull request
- One browser automation tool: Playwright or Selenium
- Locators and waits, two common causes of flaky tests
- How to structure tests: the Page Object Model, test data and fixtures
- Running tests automatically in a CI pipeline such as GitHub Actions
- Reading a failed test report: screenshots, traces and logs, and telling a real bug from a flaky test
Common mistake: adding a fixed wait like sleep(5000) to fix a flaky test. It hides the real problem and slows every run. Wait for the element or the response instead.
Exit criteria
Move to Step 4 when:
- You can automate one full user flow, such as login to logout, and it gives the same result on every run.
- Your tests start by themselves on every code push.
Practise this step
Free practice sites
- The InternetOne page for each tricky thing: dynamic loading, iframes, alerts and file upload. Automate them one by one.
- Playwright TodoMVC demoA simple to-do app. A good first full flow: add, complete, filter and delete.
- SauceDemoThe same shop from Step 1. This time, automate the whole journey from login to checkout as one test.
Guides for this step
Step 4
Performance testing
A feature that works for one user can fail for a thousand. Performance testing measures how a system behaves under load.
What to learn
- Load, stress, spike and soak tests, and the question each one answers
- The main metrics: response time percentiles (p95, p99), throughput and error rate
- Writing a test script in k6 or JMeter
- Virtual users, ramp-up and think time
- Setting pass and fail thresholds before the test runs
- Reading the results to find where the system slows down
Exit criteria
This step is complete when:
- You can run a load test against a test environment and say whether it passed, using thresholds you set in advance.
- You can explain why the 95th percentile tells you more than the average.
Practise this step
Free practice sites
- QuickPizzaA demo pizza app from Grafana, the team behind k6, made for practising load tests.
Before you run a load test: only test a site you own or have written permission to test. Even a small test can slow down a real website for the people using it.
Guides for this step
Step 5
QA career and interviews
Use this step whenever you are looking for a job or planning your next move. You do not need to finish Steps 1 to 4 first.
What to prepare
- A resume that says what you tested and what you found, not only which tools you used
- A small public project: a test plan, a set of bug reports or an automation repository
- Answers to the common interview questions for your level, in your own words
- One bug you can describe from start to finish: how you found it, how you reported it and what happened next
- A decision on direction: manual, automation (SDET), performance, or a mix
Common mistake: listing ten tools on your resume. Two tools you can talk about in depth will help you more than ten you have only installed.
Practise this step
Useful at any step
QA tools
You do not need to learn every tool on day one. Install each one when a step first needs it. All of these have a free version.
- Browser DevToolsAlready in Chrome and Edge. See network calls and console errors. Step 1 onwards.
- JiraWhere most teams track bugs and tasks. Step 1 onwards.
- PostmanSend API requests and save them in collections. Step 2.
- VS CodeA free code editor for writing your tests. Step 3.
- GitVersion control, so your tests live in a repository. Step 3.
- k6Write load tests in JavaScript and read the results. Step 4.
Guides for these tools
Is a topic missing from this path? Write to ask@testerpath.com.