Playwright Training Guide — Beginner to Professional

1. Install Node.js (the LTS version) from https://nodejs.org. Node.js is the program that runs JavaScript and TypeScript code outside a browser.
2. Install Visual Studio Code (VS Code), a free code editor.
3. In VS Code, install the extension Playwright Test for VSCode (by Microsoft).
4. Install Git from https://git-scm.com and create a free GitHub account. Git saves versions of your work; GitHub stores it online.
5. Open a terminal (the text window where you type commands) and run node -v and git --version. If both print a version number, you're set.

Learn these, in this order:

1. Variables — named boxes that hold values (const name = "Syad"; let count = 0).
2. Types — text (string), numbers (number), true/false (boolean), lists (arrays) and objects (groups of named values).
3. Conditions — if / else: do something only when a check is true.
4. Loops — for and for...of: repeat something for each item in a list.
5. Functions — reusable blocks of code that take inputs and return a result.
6. Async and await — browsers take time to load, so most Playwright commands "wait" for a result. await means "wait for this step to finish before the next one." This is the single most important concept for Playwright.
7. Error handling — try / catch: deal with something going wrong without crashing.
8. Modules — splitting code across files with import and export.

Where to learn: the free TypeScript Handbook (https://www.typescriptlang.org/docs/handbook/intro.html) or any low-cost introductory TypeScript or JavaScript course. Stay within the guide's $0–$250 budget.

Practice exercises:

1. HTML — the building blocks of a page: buttons, inputs, links, headings, forms.
2. The DOM — the live structure of a page that the browser builds from the HTML. Tests find and act on items in the DOM.
3. Developer Tools — press F12 in Chrome. Use the Elements tab to inspect any button and see its HTML.
4. Attributes — extra details on an element, like id, class, name, placeholder and data-testid.
5. Accessibility roles — every element has a role (button, link, textbox, heading). Playwright's best locators use these.
6. CSS selectors and XPath — older ways to point at elements. Know what they are; you'll prefer Playwright locators.

Practice exercises:

1. Make a new folder, open it in VS Code, and in the terminal run npm init playwright@latest. Choose TypeScript, keep the default tests folder, and say yes to installing browsers.
2. Run the example test with npx playwright test. Then open the report with npx playwright show-report.
3. Learn the shape of a test: test('name', async ({ page }) => { ... }). The page is a browser tab Playwright controls.
4. Learn the core actions: page.goto() (open a page), click(), fill() (type into a box), check(), selectOption().
5. Learn your first assertion: await expect(...).toBeVisible() and toHaveText(). An assertion is the check that decides pass or fail.
6. Try codegen: npx playwright codegen https://www.saucedemo.com. It records your clicks as code. Use it to learn, then clean up what it writes.
7. Run tests in UI mode with npx playwright test --ui to watch each step.
8. Put the project on GitHub (git init, git add, git commit, git push).

Practice exercises:

1. Preferred locators, best first: getByRole() (by role and visible name), getByLabel(), getByPlaceholder(), getByText(), getByTestId(). Use CSS or XPath only as a last resort. A locator is how a test points at an element.
2. Auto-waiting — Playwright waits for elements to be ready before acting. Never add fixed waits like waitForTimeout(3000); they make tests slow and flaky.
3. Web-first assertions — toBeVisible(), toHaveText(), toHaveValue(), toHaveURL(), toHaveCount(), toBeEnabled(). These retry until they pass or time out.
4. Test design basics — for each feature, write positive tests (it works), negative tests (bad input is rejected) and boundary tests (values at the edges, like an empty box or the maximum length).
5. Independent tests — each test sets up what it needs and doesn't depend on another test running first.
6. Hooks — test.beforeEach() runs setup (like logging in) before every test in a file. test.describe() groups related tests.
7. Clear names — a test name should say what it proves: "locked-out user sees an error message."

Practice exercises:

Next step: once you pass this checkpoint, start the Postman and API Testing Training Guide at Stage 0.

1. Page Object Model (POM) — a pattern where each page of the app gets its own file (a "class") holding its locators and actions. Tests then read like plain steps: loginPage.login(user, password). When the app changes, you fix one file, not fifty tests.
2. Fixtures — Playwright's way to hand ready-made things to a test, like a logged-in page or a page object. Learn to write a custom fixture with test.extend().
3. Test data — keep usernames, products and expected messages in a separate data file instead of typing them into every test.
4. Configuration — learn playwright.config.ts: the base URL, which browsers to run (Chromium, Firefox, WebKit), timeouts, retries and screenshots on failure.
5. Environment variables — keep passwords and URLs out of your code using a .env file that is never uploaded to GitHub. Add it to .gitignore.
6. Folder structure — a common layout: tests/, pages/, fixtures/, data/.
7. README — explain what the project tests, how to install it and how to run it.

Practice exercises:

1. Read the error — Playwright tells you which line failed, what it expected and what it got. Start there.
2. Debug mode — npx playwright test --debug pauses on each step so you can watch and step through.
3. Trace Viewer — turn on traces in the config. A trace records every step, screenshot, network call and console message. Open it with npx playwright show-trace. Professionals rely on this daily.
4. Screenshots and video — set them to save only on failure.
5. Flaky tests — tests that pass sometimes and fail other times. Common causes: fixed waits, tests that depend on each other, shared test data, weak locators and timing issues. Fix the cause; don't just add retries.
6. Reports — the built-in HTML report shows passes, failures and traces. Learn to read it and to share it.
7. Bug reports — when a test finds a real bug, write it up: steps to reproduce, expected result, actual result, screenshot or trace.

Practice exercises:

1. Git habits — small commits with clear messages, working on a branch (a separate line of work), then merging. Learn git status, git log, git branch, git checkout and git pull.
2. Pull requests — on GitHub, propose a change from a branch and review it before merging. Teams work this way.
3. GitHub Actions — GitHub's free system for running tasks automatically. The settings live in a YAML file, a plain-text settings file where indentation matters. When you installed Playwright it offered to create one at .github/workflows/playwright.yml.
4. Make the workflow run your tests on every push and pull request, and save the HTML report as a downloadable "artifact."
5. Secrets — store passwords in GitHub's repository Secrets, never in the code or the YAML file.
6. Add a status badge to your README showing whether the tests currently pass.
7. Learn the free GitHub Skills courses at https://skills.github.com for Git fundamentals and Actions.

Practice exercises:

1. Saved login (authentication state) — log in once in a setup step, save the session with storageState, and reuse it so tests don't log in every time. This makes suites much faster.
2. API testing inside Playwright — the request fixture sends calls straight to an API (no browser). Use it to check responses, status codes and data. It ties in with Route 2.
3. API setup for UI tests — create test data through the API before a UI test, then check it in the browser. Faster and more reliable than clicking through setup.
4. Network mocking — page.route() lets you fake a server's response, for example to test how the page shows an error when the server fails.
5. Parallel runs and sharding — run tests at the same time across workers, and split big suites across machines in CI.
6. Visual comparison — toHaveScreenshot() compares a page against a saved image to catch layout changes.
7. Mobile and cross-browser — use Playwright's device settings to test phone screen sizes.
8. Tags and filtering — tag tests like @smoke or @regression and run only those with --grep.
9. Accessibility checks — add the @axe-core/playwright package to scan pages for common accessibility problems.

Practice exercises:

1. What Selenium is — an older, widely used browser automation tool. It drives browsers through WebDriver, a standard way for code to control a browser.
2. Language — Selenium is most often used with Java or Python in job listings, but it also works with JavaScript/TypeScript (selenium-webdriver package). Start in TypeScript so you only learn the tool, not a new language.
3. Key differences from Playwright — Selenium doesn't auto-wait, so you must add explicit waits (driver.wait(until.elementLocated(...))). It has no built-in test runner, trace viewer or report; those come from other tools (Mocha, Jest, TestNG, JUnit).
4. Core commands — driver.get(), findElement(By.id / By.css / By.xpath), click(), sendKeys(), getText(), quit().
5. Page Object Model — works the same way as in Playwright. Your Stage 5 knowledge carries over.
6. Selenium Grid — runs tests across many browsers and machines. Know what it is; you don't need to set one up.
7. Be ready to explain why a team might pick Playwright or Selenium: Playwright is faster to write and more stable thanks to auto-waiting; Selenium has a longer history, more languages and huge existing suites.

Practice exercises:

A test strategy is a short document in your project explaining what you tested, what you didn't and why, which browsers, and the known risks. Write one page.

What professionals do beyond the basics:

• Review other people's test code and accept review of their own.
• Keep tests fast, independent and readable; delete tests that no longer add value.
• Choose what to automate: stable, repeated, high-risk flows first; leave one-off and visual judgment checks to manual and exploratory testing.
• Track flaky tests and fix causes instead of adding retries.
• Talk to developers in their terms: commits, pull requests, CI runs, traces.

Keep growing after this guide: Routes 2 (API testing), 3 (Git, GitHub Actions and SQL) and 4 (AI-assisted QA) build directly on this work.