Test Management for Playwright: Complete Guide

Test management for Playwright means connecting your Playwright test runs to a test management system (TMS) so results are stored with history, linked to requirements and manual test cases, and tracked as coverage over time — instead of living only in a per-run report that disappears on the next run.

Playwright is an excellent test runner, but it is not a system of record. This guide explains why Playwright's built-in reporting is not enough on its own, and how to connect Playwright to a TMS — both automatically via an npm reporter and manually via report upload.

Why Playwright's built-in reporting isn't enough on its own

Playwright ships with good reporters — the HTML reporter, the list and line reporters, JSON, and the blob reporter for sharding. They are great for inspecting a single run, but they share three limitations as soon as you run tests repeatedly across a real project:

• No history. The HTML report shows the last run. The previous run is overwritten unless you archive artifacts manually, so "is this test flaky?" and "when did this start failing?" are hard to answer.
• No traceability. A Playwright report knows nothing about your requirements or your manual test cases. There is no built-in link between an automated spec and the feature it verifies.
• No combined coverage. Most teams run automated and manual tests. Playwright only sees its own results, so your real coverage picture is split across tools.

A test management system sits on top of Playwright and fills exactly these gaps: persistent run history, traceability to requirements, and one coverage view across manual and automated testing. We cover the broader concept in our guide to what a test management system is.

What a TMS adds to a Playwright workflow

When Playwright is connected to a TMS, each run is ingested and turned into durable, queryable data. In QAM Hub specifically, that means:

• Run history — every automated run is stored with pass/fail status per test and a full history, so trends and regressions are visible over time.
• Screenshots and traces — failure screenshots from the run are uploaded and attached to the corresponding result, so you can debug without re-running locally.
• Linking to manual cases — automated results are matched back to your manual test cases through a TC-<number> prefix in the test title, connecting the two worlds.
• Automation coverage reporting — a dedicated report shows how much of your suite is covered by automation versus manual checks.

How to connect Playwright to QAM Hub

There are two ways to get Playwright results into QAM Hub: an npm reporter that pushes results automatically after every run, and a manual upload of the Playwright JSON report. Most teams use the reporter for CI and keep upload as a fallback.

Option 1 — the npm reporter (automatic push)

QAM Hub publishes an official Playwright reporter on npm: @qamadness/qam-playwright-reporter. It plugs into your existing playwright.config.ts and submits results to your QAM Hub project automatically when the run finishes.

Install the package (Playwright 1.30 or newer is required):

npm i -D @qamadness/qam-playwright-reporter

Add it to the reporter array in playwright.config.ts. The reporter reads Playwright's built-in JSON report, so the json reporter must be enabled alongside it:

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

export default defineConfig({
  reporter: [
    ['json', { outputFile: 'test-results/report.json' }],
    ['@qamadness/qam-playwright-reporter', {
      apiUrl: process.env.QAM_API_URL!,        // base URL of the QAM Hub API
      projectId: process.env.QAM_PROJECT_ID!,  // project UUID from QAM Hub
      runName: `CI Run ${process.env.CI_BUILD_NUMBER ?? new Date().toISOString()}`,
      // apiToken is read from the QAM_API_TOKEN env var automatically
    }],
  ],
});

Only apiUrl and projectId are required. The project UUID is shown on the QAM Hub Automation Runs page. Optional settings include runName (a human-readable name for the run) and disabled (set to true to skip submission on local runs).

Authentication

Generate a Bearer token in QAM Hub under Profile → API Tokens and expose it as the QAM_API_TOKEN environment variable — ideally as a CI secret. The reporter reads it automatically, so it never needs to appear in your config or be committed to the repo.

Linking results to manual cases

To auto-link an automated result to its manual test case, prefix the test title with TC-<number>, where the number matches the manual case in QAM Hub:

test('TC-42: user can log in', async ({ page }) => {
  // ...
});

Because results flow automatically when the run completes, this reporter is the recommended setup for continuous integration.

Option 2 — upload the Playwright JSON report

If you prefer not to add the reporter, or you are wiring up CI incrementally, you can upload Playwright's JSON report directly. Generate it with the JSON reporter:

npx playwright test --reporter=json > results.json

Then upload the JSON file in your QAM Hub project's automation section. QAM Hub parses the report into its suite hierarchy and attaches screenshots. Step-by-step instructions are in the Knowledge Base article on uploading Playwright reports.

Linking automated results to manual test cases

The single most useful thing a TMS does for a Playwright workflow is connect automated and manual testing. In QAM Hub, an automated result is linked to a manual test case when the test title carries the matching TC-<number> prefix, so a single case can show both its manual execution history and its latest automated result.

This matters during the transition from manual to automation: you can see at a glance which cases are already automated, which still need a human, and what your true coverage is — rather than guessing. We go deeper on that journey in manual to automation: what to automate first.

Tracking automation coverage over time

Once runs are flowing in, QAM Hub's automation and coverage reports answer the questions a raw Playwright report cannot: what percentage of the suite is automated, which areas are covered, and how pass rates trend across runs. Tied to requirements traceability, this connects your Playwright suite back to what the release actually needs to deliver — see our guide to the requirements traceability matrix.

Going further: driving the TMS from AI agents

Beyond ingesting results, QAM Hub exposes a Model Context Protocol (MCP) server, which lets AI agents read and manage test artifacts programmatically — including results produced by Playwright. If you are exploring AI-assisted QA, see connecting Claude to your TMS via MCP.

Frequently asked questions

Does a TMS replace Playwright?

No. Playwright runs the tests; a TMS organizes and tracks the results. They are complementary — Playwright is the execution engine, the TMS is the system of record for history, traceability, and coverage across both automated and manual testing.

How do Playwright results get into the TMS?

Two ways: the official npm reporter (@qamadness/qam-playwright-reporter) added to playwright.config.ts, which pushes results automatically after each run, or a manual upload of Playwright's JSON report. The reporter is best for CI; upload works as a fallback.

How are automated and manual tests for the same feature linked?

By prefixing the Playwright test title with TC-<number>, where the number matches the manual case in QAM Hub. The case then shows both its manual execution history and its latest automated result in one combined view.

Does this work in CI/CD?

Yes. The npm reporter runs wherever Playwright runs, including CI pipelines, and pushes results automatically when the run completes. Store your API token as a CI secret in the QAM_API_TOKEN environment variable. See managing automated test results in a TMS for CI patterns.

Summary

Playwright is a powerful test runner, but its reports are per-run and isolated. Connecting Playwright to a test management system gives those runs persistent history, traceability to requirements, and a single coverage view across manual and automated testing — turning isolated runs into a system of record.

QAM Hub is a test management system built by QA Madness, a software testing and QA automation company. It ingests Playwright and Cypress results, links them to manual cases, and reports coverage in one workspace — built by QA engineers who automate testing every day.