How to Use Claude Code for QA Automation: Plan, Write and Run Playwright Tests

You will learn: how to bound the task in plan mode, use browser inspection without confusing it with a repeatable test, choose robust locators, read a failed trace, and decide whether an unattended run is safe.

The working path in five steps

1. Give Claude Code the repository, test command, and one user journey. Ask it to inspect before editing.
2. Review its plan, including the expected behavior, setup, locator choices, and assertions.
3. Let it add one Playwright test. Use Playwright MCP only when live browser inspection will clarify the page.
4. Run the new test with the project's existing runner. Keep the terminal output and a failure trace.
5. Read the diff and repeat the run yourself before merging.

Anthropic's Claude Code test workflow explicitly includes finding uncovered code, adding meaningful edge cases, and running the new tests. The Playwright writing guide supplies the browser runner and assertions. These are complementary jobs, not two names for the same tool.

1. Put the agent in planning mode first

From the project root, open Claude Code and switch to plan mode. Anthropic documents the startup command and the in-session mode switch in its plan-before-editing guide. In plan mode Claude reads the files and proposes changes without writing them. That gives you a chance to catch the wrong route, account state, or assertion before a test file appears.

Give it a narrow prompt such as:

Inspect our existing Playwright configuration and tests. Plan one browser test for a signed-out visitor who submits the contact form and sees the success state. State the route, required test data, locators, assertions, and exact command to run. Do not edit files until I approve the plan. Do not use production credentials or submit to the live site.

Replace the example route and expected state with your application's real behavior. If the plan invents a route or assumes a test account exists, correct it before approving edits. If the page requires a network service, say which local or staging environment the test may use. A passing browser click is not proof that the right business outcome happened.

Ask for one edge case in the same plan, such as an empty required field. Keep it as a separate test if it has a different expected result. Claude Code can inspect nearby tests for conventions, but it cannot infer a product requirement that you have never recorded.

2. Draft a repeatable Playwright test

A useful test names the user outcome, uses a fresh context, and asserts something the user can see. The Playwright fixture documentation explains why each test receives its own page. The locator guide favors roles, labels, and other user-facing selectors over fragile DOM paths.

Here is the shape for a small, public demo. The TodoMVC route is a demonstration site, not a Xtrusio product screen:

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

test('a completed task stays visible', async ({ page }) => {
await page.goto('https://demo.playwright.dev/todomvc/');
const input = page.getByPlaceholder('What needs to be done?');
await input.fill('Review release notes');
await input.press('Enter');

const item = page.getByRole('listitem').filter({ hasText: 'Review release notes' });
await item.getByRole('checkbox').check();
await expect(item.getByRole('checkbox')).toBeChecked();
await expect(item).toBeVisible();
});
```

On 19 October 2026, we checked those browser actions with the locally available Playwright browser against the public TodoMVC demo. The task appeared and its checkbox was checked. The captured browser result shows that demo state. We then asked the installed Claude Code CLI to read our existing check and write one Playwright Test case. It wrote one test file without running a command or changing another file. The first runner attempt said No tests found: the generated filename ended in .ts, so we renamed it to .spec.ts. The second attempt failed before opening the page. Our temporary test folder had no project package.json and imported a locally installed Playwright package by directory, which Node's ES module resolver rejected. For that isolated test only, we changed the import path to the package's index.js file. In a normal Playwright project, use import { test, expect } from '@playwright/test' as shown above; do not copy our temporary folder's path workaround. The focused run then reported 1 passed (13.4s) on the public demo. This is a local demo, not a production QA result or proof that every generated test will work first time.

If the generated test uses a long CSS chain or a guessed test ID, stop and inspect the page. A test that passes today only because it clicks the third button may fail on the next harmless layout change. Also ask what the assertion proves: seeing a toast after a form click may be weaker than seeing the submitted record in a test environment.

3. Use Playwright MCP for inspection, then keep tests in the repository

The official Playwright guide for Claude Code shows how to connect Playwright MCP. That connection lets the agent inspect and interact with a browser while it works. It does not replace a checked-in Playwright test, a stable fixture, or your CI run. Anthropic's MCP documentation explains how Claude Code manages external tools and how to inspect their connection state.

Before adding any MCP server, follow your organization's software approval policy. Read the official setup page and the package source, choose a test environment, and keep production credentials out of the agent session. Once connected, ask Claude Code to open the intended test page and report the accessible names of the form fields, buttons, and resulting status. Then have it write those observations into the test using Playwright locators. Review the code before it is run.

This separation prevents a common mistake: an agent can click through a page once in an interactive browser, yet never save a repeatable assertion. Browser exploration is evidence for the next edit; the repository test is what the team can rerun.

4. Run the test and inspect what failed

Use the test command already defined by your repository. In a standard Playwright project, the running-tests guide shows a focused run with npx playwright test followed by the test file path. That command uses the installed project dependency; it is not a reason to install a new version mid-review.

If a test fails, separate three questions:

• Did the application actually violate the requirement?
• Did the locator select the wrong element or become ambiguous?
• Did test setup, timing, or an external service fail before the assertion?

Playwright's trace viewer can show the action sequence, DOM snapshots, and screenshots for a recorded test. Capture traces on failures or retries according to your project's policy. The locator documentation and Playwright's retrying assertions help avoid arbitrary sleeps. A retry can help diagnose an intermittent failure, but a green retry does not make the original failure irrelevant.

Ask Claude Code to explain a failure using the actual output and trace. If it proposes a longer timeout, ask first which condition the test is waiting for. If it proposes an API that is absent from your installed Playwright version, reject the edit and consult that version's documentation. An agent's plausible method name is not evidence that the method exists.

5. Review the agent's changes before merging

Read the diff line by line. Confirm that it touched only the intended test and fixtures; did not weaken an assertion; did not delete a failing case; did not add credentials; and did not silently change the application to make the test pass. Run the focused test yourself, then the surrounding suite required by your repository. Anthropic's common-workflow guide advises reviewing generated changes and running tests; it does not promise that an agent can approve its own work.

For a test that performs a real mutation, use disposable data and an isolated environment. Record the exact command and the pass or failure result in the pull request. If a browser action reaches production, treat it as a release-risk decision, not a convenience setting for the agent.

What about overnight agents and free config packs?

Short social clips often compress the process into “leave an agent running overnight.” That can be useful only after its write scope, test environment, credentials, network access, and stopping conditions are explicit. Plan mode and a small first test are the safer starting point. An unattended run still needs a human diff and failure review before merge.

The open-source Everything Claude Code repository offers configuration, rules, and workflow material. Its availability does not certify those files for your repo. Read the actual rules and hooks, verify what commands they can run, and check their provenance before adopting them. No community config can tell you what your product's success state should be.

Measure whether this guide is cited in AI answers

If you publish a QA guide, test the specific buyer question it answers, for example “How do I use Claude Code to write and run a Playwright form test?” Save the dated answer, the query, and its cited URLs. After the guide is live, repeat that question in the same engine and check whether the answer cites the exact guide URL. A brand mention alone and a domain-only link are different observations from an exact-page citation.

Xtrusio's AI visibility guide explains why the question, answer, and cited sources matter. The practical point is to measure whether the guide solved a real sub-question and became a cited source, rather than treating publication itself as proof of visibility. This section describes a method, not a promise that an engine will cite this page.

Sources and scope

Official pages checked 19 October 2026: Anthropic Claude Code common workflows, Anthropic MCP guide, Playwright Claude Code MCP guide, Playwright writing tests, Playwright locators, Playwright running tests, Playwright trace viewer, and the original Everything Claude Code repository. Our dated Claude Code and browser check covered the public TodoMVC demo only. No production suite or unattended-agent benchmark is claimed.