Test Automation Learning Path: Start Here

In short: you learn test automation in 6 milestones, and each one adds a layer to one framework you keep building — from three plain tests to a suite with page objects, fixtures, an API layer, CI, mocking and visual checks. Every milestone has a tested solution to compare with.

How to use this page

Read this page once to see the plan. Then, for each milestone, follow the same four steps: learn → build → check → commit. Come back here whenever you're unsure what to do next.

Before you start

• You can write basic TypeScript or JavaScript: variables, functions, async/await, classes. (Java or Python instead? The ideas are the same — see Other tools.)
• You know Git basics — see the Git cheat sheet.
• You know what to test — the manual testing path (at least Milestones 1–3) makes this path much easier.
• Node.js 20+ is installed.

The pages in this learning path

In short: each page has one job, so nothing is explained twice.

Page	What it's for	When to open it
This roadmap	The plan: what each milestone covers and how to check yourself	At the start of each milestone
Test automation cheat sheet	Learn each idea: short explanation, example, exercise	The "learn" step of every milestone
Milestones & Mini-Projects	What to build in each milestone, with tested solutions	The "build" and "check" steps
Quick Reference	Locators, assertions, CLI, config, errors and fixes	Any time you're writing tests
Best Practices	Habits that keep a suite fast and trusted	After Milestone 3, then on every pull request
Framework implementation guide	The finished framework explained layer by layer	When you want the deeper "why"

The milestones

In short: do them in order — each milestone changes the same project.

Milestone	You learn	You build	Rough time
1	Set-up, locators, actions, assertions, running	Three login tests	1 week
2	Page objects, test data	LoginPage, InventoryPage, a sorting test	1–2 weeks
3	Fixtures, saved logins, independence	Fixtures + a cart test that starts logged in	1–2 weeks
4	API testing in code, builders, negative tests	An API client and booking tests	1–2 weeks
5	Config, tags, reports, CI	Browser projects, tiers, a GitHub Actions pipeline	1 week
6	Mocking, visual tests, flaky and known-bug handling	Mocked-API tests, a visual test, known-bug tests	1–2 weeks

Times assume about 6 hours a week.

For each milestone:

1. Learn — read the cheat-sheet sections listed below and run their examples.
2. Build — do the tasks in Milestones & Mini-Projects.
3. Check — run the check command. Only when it passes, open the solution and compare designs.
4. Commit — one commit (or pull request) per milestone:

git add .
git commit -m "Milestone 2: page objects for login and inventory, sorting test"

Milestone 1: First tests

Learn: What automation is · Set-up · Your first test · Finding elements · Actions · Assertions · Running & debugging · Grouping & hooks

Build: Three login tests

Check yourself:

• What happens if you forget await before an action?
• Why is getByRole preferred over a CSS selector?
• What's the difference between expect(locator).toHaveText() and expect(text).toBe()?

Milestone 2: Page objects

Learn: Page objects · Test data · Quick Reference: Locators

Build: Page objects and a sorting test

Check yourself:

• If the login button's text changes, how many files do you edit?
• Why should page objects avoid if statements about test data?
• What does filter({ hasText }) do, and why is it needed on a product list?

Milestone 3: Fixtures & saved logins

Learn: Fixtures · Parallel & independent · Saved logins · Quick Reference: Fixture pattern

Build: Fixtures and a logged-in cart test

Then read: Best Practices, sections 1–7.

Check yourself:

• When does the code after use() in a fixture run?
• Why may a test file not import another test file?
• Why must .auth/ never be committed?

Milestone 4: API layer

Learn: API calls in tests · Test data · API testing cheat sheet, sections 1–12

Build: An API client and booking tests

Check yourself:

• Why create UI test data through the API?
• What makes a negative API test valuable?
• How does a data builder keep parallel tests from clashing?

Milestone 5: Config, tags & CI

Learn: Config & environments · Tags & tiers · Reports & traces · Running in CI · Sharding · Quick Reference: Config options, CLI

Build: Projects, tiers and a pipeline

Check yourself:

• Which tier runs on a pull request, and which nightly? Why?
• Why retry only in CI?
• Why upload the report with if: ${{ !cancelled() }}?

Milestone 6: Resilience

Learn: Network mocking · Visual testing · Flaky tests · Known bugs · Quick Reference: Errors and fixes

Build: Mocking, visual and known-bug tests

Then read: Best Practices, sections 8–14.

Check yourself:

• When would you mock an API, and when must you not?
• Why are visual baselines stored per operating system?
• What's the difference between test.fail() and test.skip()?

When you get stuck

Problem	What to do
A locator can't find the element	Run npx playwright codegen https://www.saucedemo.com and click the element; or open --ui and use the locator picker
strict mode violation	Your locator matches several elements — add a name, a filter, or scope it inside a card
Test passes alone, fails in the full run	Shared data or order dependence — see Parallel & independent
TypeScript errors	npx tsc -p . shows them all at once; see Errors and fixes
The practice site changed	Update the locator — that's real-world maintenance, and good practice

What's next

• Go deeper on APIs: API testing learning path.
• Advise others: Automation consulting and strategy.
• Automate mobile apps: Appium guide.

Good resources to use alongside: the official Playwright docs and their "Best Practices" page, and the ISTQB Advanced Test Automation Engineering syllabus for the architecture vocabulary.