Start a Playwright test project with QAStarter

1. Choose a stack you can maintain

Before generating a framework, decide which language your team will maintain and which environments it needs to run in. A familiar stack is usually easier to debug than one selected only for its feature list.

Open QAStarter, launch the generator, and select an available Playwright combination. Review the options for project structure and CI. The generator provides source code and sample tests; it cannot know your application's business rules.

2. Generate, download, and inspect

Download the generated ZIP and extract it into a new project directory. Open its README before running commands. Installation and test commands depend on the selected language and template, so use the generated instructions as your reference.

Review the dependency manifest, configuration, test folders, page objects, and CI workflow. Keep credentials out of committed files. Create a local environment configuration for the application URL and any dedicated test account.

3. Configure the application under test

Use a test or staging environment with known data. Start with one stable user journey and an assertion that tells you whether the behavior worked. A test that only opens a browser does not establish useful coverage.

For a TypeScript Playwright project, the configuration can read a base URL from the environment. The following is an illustrative configuration fragment; adapt it to the files generated by your selected template.

Illustrative playwright.config.ts

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  use: { baseURL: process.env.BASE_URL },
  reporter: [['html']],
});

4. Make the first test prove something

Install dependencies and browser binaries using the generated README. Run an included sample, then adapt it to a page and behavior your application actually exposes. Prefer stable user-facing roles or explicit test identifiers over brittle DOM selectors.

For example, a health page might expose a heading named System status. The example below checks that specific visible result. Replace the path and heading with a real contract in your application.

Illustrative TypeScript test

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

test('shows the service status', async ({ page }) => {
  await page.goto('/status');
  await expect(
    page.getByRole('heading', { name: 'System status' })
  ).toBeVisible();
});

5. Run the same test in CI

Commit the project to your repository after reviewing generated files. Configure the CI runner's language runtime, browser dependencies, environment variables, and test account secrets. Run the same commands that worked locally.

Make test reports and failure artifacts available to reviewers. Establish a small reliable suite before adding parallel workers, more browsers, or more environments. If the first test is unstable, investigate its data, selectors, timing, and environment before expanding coverage.

QAStarter gets the framework in place. Your team owns the assertions, test data, CI permissions, and maintenance decisions that make it useful.

← All QATonic guides