How to start regression automation in Playwright

Why regression takes too long

Manual regression grows with the product. Every new feature adds scenarios to check before release, while the number of people clicking through them usually stays the same. In one of my projects, regression automation cut execution time by 80%, not because we automated everything, but because we automated the right things in the right order.

Automation makes sense when:

• you check the same scenarios before every release,
• the feature is stable and doesn’t change every sprint,
• a bug in that place is expensive (login, payment, order).

Your first Playwright test

Start with a scenario the team checks manually before every release anyway, such as login. A test should have one responsibility and use role- and label-based locators rather than CSS classes. Running npx playwright test executes it locally.

import { test, expect } from '@playwright/test';

test('logs the user in with valid credentials', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('[email protected]');
  await page.getByLabel('Password').fill(process.env.QA_PASSWORD!);
  await page.getByRole('button', { name: 'Log in' }).click();
  // expected result: the user dashboard
  await expect(page.getByRole('heading', { level: 1 })).toHaveText('Dashboard');
});

getByRole and getByLabel locators work the way a user sees the page. A changed CSS class or div structure won’t break them, and they also expose accessibility issues such as a field without a label.

Project structure

A few rules that save hours of maintenance:

• One file, one functional area. login.spec.ts, checkout.spec.ts, not tests1.spec.ts.
• Test data outside the tests. Keep accounts, products and addresses in fixtures or create them via the API before the test.
• Log in once. Playwright can save an authenticated session (storageState) and reuse it. Don’t log in through the UI in every test.
• Independent tests. Every test must run on its own, in any order. Otherwise parallel runs turn into a lottery.

Don’t automate a scenario that changes every sprint. Wait until the feature is stable.

What to automate first

List your regression scenarios and rate each on two axes: how often you check it and how much a bug costs. Start with those that score high on both.

The numbers are illustrative, but the proportions match what I see in projects.

When to plug the tests into CI

From day one. A test that only runs on the author’s laptop doesn’t protect against regression. Start by running the tests on every pull request to the main branch, with the HTML report as an artifact. Playwright generates it with one command and shows screenshots and a trace for failed tests.

As the suite grows, split it into a fast smoke run (a few minutes, on every PR) and full regression (nightly or before a release). I cover the details in the guide Regression in CI.

Summary

Regression automation isn’t a “let’s write tests for everything” project. It’s a series of small steps: one stable scenario running in CI, then the next. If you’d like help getting started or cleaning up existing tests, describe your project.