Test Automation Tutorial: From Zero to a Green Suite in One Afternoon

1. What Test Automation Actually Is

Test automation is the practice of replacing repetitive manual verification with code that drives your application the way a user would, then asserts on the result. Every time a human would click a button and check that the next screen shows the right number, an automated test can do the same thing in milliseconds, deterministically, across every browser and viewport your users actually use.

Most tutorials spend their first thousand words on testing theory. This one will not. You will need three mental models and nothing else: a test runner (the thing that executes your tests), a browser driver (the thing that controls the browser), and a locator strategy (the thing that tells the driver which element to interact with). Playwright bundles all three into a single npm package, which is why this tutorial starts there.

2. Choose Your Stack (and Why Playwright)

Before you install anything, you need to pick a framework. There are dozens, but for a 2026 test automation tutorial the honest answer is Playwright. It supports Chromium, Firefox, and WebKit out of the box. It auto-waits for elements, which eliminates most of the race conditions that make older frameworks flaky. It has a first-class trace viewer. And it is free, open source, and maintained by Microsoft.

Cypress is a reasonable alternative if you only test Chromium-based browsers and you never need to drive multiple tabs at once. Selenium is still around, but its architecture shows its age and its locator APIs are significantly more brittle than Playwright's. For a tutorial that teaches patterns you can use for the next five years, Playwright is the pragmatic choice.

3. Install Playwright and Set Up Your Project

Open a terminal in your project root. You need Node.js 18 or later. If you are starting fresh, create a new directory first. Then run the Playwright init command, which installs the test runner, downloads the browser binaries, and writes a baseline config file.

The init command creates four important files: playwright.config.ts (runner configuration), tests/example.spec.ts (a starter test), a .github/workflows/playwright.yml file for CI, and a tests-examples directory you can delete. The config file is where you will later configure cross-browser projects, retries, and the base URL for your app.

4. Write Your First Test

Delete the example test and create a new file at tests/homepage.spec.ts. The anatomy of every Playwright test is the same: import test and expect, declare a test block with a description, use the injected page fixture to drive a browser, and assert on the result.

Run it with npx playwright test. The runner starts your dev server via the webServer config, launches Chromium, Firefox, and WebKit in parallel, executes the test in each, and produces an HTML report. Your first test suite is live.

5. Locators: The Heart of Resilient Automation

Most flaky tests come from bad locators, not bad code. The difference between a test suite that stays green for a year and one that breaks every sprint is almost entirely locator discipline. The rule is simple: prefer locators that target semantics (role, label, text) over locators that target implementation details (CSS classes, DOM hierarchy, auto- generated IDs).

// Fragile: breaks when markup changes
await page.click('.btn.btn-primary.mt-4');
await page.click('div > div:nth-child(3) > button');
await page.click('#user-menu-dropdown-trigger-v2');
await page.locator('xpath=//div[@class="card"]//button[2]').click();

// Any refactor breaks these.
// Class rename? Broken.
// Extra wrapper div? Broken.
// New ID suffix from a build tool? Broken.

Playwright provides a clear locator hierarchy. Reach for each one in order until you find one that works. The higher you land on this list, the more resilient your test will be to UI refactoring.

6. Real Scenarios: Login, CRUD, and Payments

A homepage smoke test proves the toolchain works. Real coverage starts when you test the flows users actually care about. Below are three scenarios that map directly to the critical paths of most SaaS apps. Each one is a runnable Playwright test you can adapt to your own application.

Notice that every interactive element in these tests is found by getByRole or getByLabel. That is not an accident. Accessibility-first locators also happen to be the most refactor-resistant locators, which is why teams that care about a11y usually end up with the least flaky test suites too.

7. Debugging Failures With Trace Viewer

Every test you write will eventually fail in CI, and when it does you need to know why without rerunning it locally. This is where Playwright's trace viewer changes the game. A trace file captures a full recording of the test: every DOM snapshot, every network request, every console message, every action timing. You can open one locally and scrub backward and forward through the test like a video.

The config you wrote in section 3 already enables traces on first retry. When a test fails twice in CI, Playwright writes a trace.zip under test-results/. Upload it as a build artifact, download it, and open it with npx playwright show-trace trace.zip.

Three debugging commands cover 90% of real failures. Memorize them.

8. Running the Suite in CI

A test suite that only runs on your laptop catches nothing. The real value of automation is a suite that runs on every commit, blocks broken pull requests, and sends the author a trace they can click into. The GitHub Actions workflow below is the minimum viable CI setup. Adapt it for GitLab CI, CircleCI, or Jenkins with the same three logical steps: install, run, upload artifacts.

Two details matter most here. The --with-deps flag on the install command ensures the runner downloads the correct browser system libraries for the Ubuntu image, which saves you from cryptic failures about missing libnss3. The upload-artifact step runs on always() so the HTML report is available for passing runs too, not just failures. When a test starts flaking, you will want the historical reports.

9. Scaling Coverage With AI Generation

Once you have five tests you feel good about, the honest question is how you get to fifty without spending a month on it. Manual test authoring costs two to four hours per scenario when you include writing, debugging, and stabilizing. For a solo developer or a lean team, that math does not work.

This is where AI test generation closes the gap. Assrt is an open-source tool that points a headless browser at your running app, builds an interaction graph from the accessibility tree, and generates standard Playwright .spec.ts files for every flow it discovers. The output is real code you can read, edit, commit, and run with npx playwright test. Unlike proprietary platforms that charge $7,500 per month and lock your tests behind their cloud runner, Assrt is free and self-hosted, and the generated tests are yours to keep forever.

# What you get from most AI testing platforms:
# proprietary YAML locked to their cloud runner.
name: login_test
tags: [smoke, auth]
steps:
  - visit: /login
  - fill:
      selector: "#email"
      value: "demo@example.com"
  - fill:
      selector: "#password"
      value: "pass1234"
  - click:
      text: "Sign in"
  - assert:
      url_matches: "/dashboard"

# Cancel subscription = tests stop running.
# Estimated lock-in cost over 3 years: $270,000.

The workflow that scales: write the critical path tests by hand so you learn the patterns, then use generation to cover everything else. Review the generated tests with the same care you would give a pull request from a junior engineer. Commit the ones that look right. Fix the ones that do not. Your coverage grows by an order of magnitude in a single afternoon, and the suite stays entirely under your control because every file is a plain TypeScript spec that lives in your repository.

10. FAQ

Do I need to know TypeScript to follow this tutorial?

Basic JavaScript is enough. Playwright's API is small and the tests in this tutorial use only a dozen functions. If you have written a fetch call, you can write a Playwright test. The TypeScript types are there to help you autocomplete locators, not to get in your way.

How long should a good test suite take to run?

For a medium-sized SaaS app, aim for under 10 minutes end to end in CI with parallel sharding. Smoke tests on every commit should run in 2 to 3 minutes. If your suite is slower than that, parallelize with Playwright's workers, shard across multiple CI runners, and move any expensive setup into shared fixtures.

Should I use Page Object Model?

For small suites, no. Write tests flat and duplicate locators until the duplication actually hurts. When you have 30+ tests that share a locator, extract it into a helper. Premature POM abstraction is one of the fastest ways to make a test suite harder to read and harder to maintain.

What if my tests are flaky?

Flakiness is almost always caused by one of three things: bad locators (use getByRole instead of CSS selectors), missing auto-wait (use toBeVisible and toHaveURL instead of fixed timeouts), or shared test state (use storage state files and fresh browser contexts per test). Fix all three and your flake rate drops toward zero.

Is Playwright free for commercial use?

Yes. Playwright is released under the Apache 2.0 license and is free for any commercial use. Microsoft maintains it and ships a new version roughly every six weeks. No seat licenses, no CI minute limits, no vendor portal to log into.

How does Assrt compare to commercial AI testing platforms?

Commercial platforms like QA Wolf, Mabl, and Testim charge $300 to $7,500 per month and lock your tests into proprietary formats. Assrt is open source and free, runs entirely on your own infrastructure, and emits standard Playwright code you can version in Git and run anywhere. If you uninstall Assrt, every generated test keeps working. Tests are yours to keep.