How to use Claude Code for QA automation

What Claude Code can do in a QA workflow

• Generate unit tests for a module, in the project's existing style and framework.
• Turn a bug report into a failing regression test, then fix the code until it passes.
• Add missing edge cases to an existing suite (empty input, unicode, timeouts, concurrency).
• Write end-to-end tests for Playwright or Cypress and, with a browser MCP server, run them against a live app.
• Triage a red CI run: read the log, find the cause, propose or apply the fix.
• Review a pull request for untested paths and post the findings.

What it cannot do is decide what matters. It will happily reach 100% line coverage with tests that assert nothing useful. The quality of the output tracks the quality of the instruction, which is why the setup below starts with the memory file rather than the prompt.

Setup: tell it how tests run

# CLAUDE.md
## Testing
- Unit tests: `npm test` (vitest). Files live next to the source as `*.test.ts`.
- E2E: `npx playwright test`, specs in `e2e/`. Needs the dev server: `npm run dev`.
- Always run the relevant test file after editing it. Do not mark a test `.skip` to make the suite pass.
- Prefer table-driven tests; one behaviour per `it()`; no snapshot tests for logic.

That block is the difference between an agent that guesses and one that behaves like a colleague who has read the contributing guide. Add the assertion style you want and the things you never want (mocking the database, skipping tests, editing fixtures to match wrong output).

Generate tests from a spec or a bug report

> Read src/billing/prorate.ts. Write vitest tests covering the documented behaviour in
  docs/billing.md, including month boundaries, leap years and a zero-day period.
  Run them; if any fail, tell me whether the code or the doc is wrong before changing code.

> Bug #412: uploading a 0-byte file returns 500 instead of 400. Write a failing test that
  reproduces it, then fix the handler so the test passes. Do not touch other tests.

The last sentence of each prompt matters. "Tell me whether the code or the doc is wrong" stops it from silently changing behaviour to match a test it just invented; "do not touch other tests" stops the classic failure mode where it edits an unrelated assertion to get green.

The run–fix loop

Ask it to run the test after writing it. It reads the failure output, adjusts, and re-runs — usually two or three iterations. Watch the permission prompts: allow Bash(npm test*) and Bash(npx playwright test*) once with /permissions so the loop is not interrupted, and keep destructive commands on ask. If it loops more than four or five times on one test, stop it; the test is probably asserting the wrong thing and a human should look.

Headless in CI

# generate regression tests for whatever changed, non-interactively
git diff --name-only origin/main...HEAD | grep -E 'src/.*\.ts$' > changed.txt
claude -p "For each file in changed.txt, add or extend tests for the changed behaviour. Run them." \
  --allowedTools "Read,Edit,Write,Bash(npm test*),Bash(git diff*)" \
  --max-turns 25 --output-format json > claude-qa.json

Print mode never asks a question, so everything it may do has to be pre-approved with --allowedTools, and --max-turns caps the loop. Set ANTHROPIC_BASE_URL=https://aiprimetech.io and a gateway key as CI secrets and the run bills against your gateway balance or unlimited plan. Commit the result to a branch and let a human review it — do not auto-merge generated tests.

On every pull request: the GitHub Action

The Claude Code GitHub Action runs the same loop when someone comments @claude on a pull request, or automatically on open. A QA-flavoured instruction in the workflow — "review this PR for untested branches and add tests for them" — gives every PR a first pass before a reviewer looks. The GitHub guide covers the App install, the workflow file and the costs.

End-to-end tests with Playwright

Two levels. Without a browser, it writes Playwright specs from the page structure and your description and you run them. With a Playwright MCP server connected (/mcp), it can open the app, click through the flow, read the DOM and write a test that matches what it saw — much more reliable selectors, at the cost of a longer session. Keep browser sessions to one flow each and /clear between them; screenshots and DOM dumps are large and are resent on every turn.

Keeping QA runs cheap

• Use the Sonnet tier; test generation rarely needs Opus. The Haiku tier is fine for triaging logs.
• Point it at one module or one bug at a time. "Add tests for the whole repo" is the most expensive prompt there is.
• /compact after each test file lands; the failure logs it read are no longer useful.
• In CI, cap with --max-turns and run only on changed files.
• For a team running this daily, a flat-rate unlimited plan removes the per-token question entirely.

Plan	Duration	Price
Unlimited 1 Hour	1 hour	$1
Unlimited 24 Hours	24 hours	$10
Unlimited 1 Week	1 week	$49
Unlimited 15 Days	15 days	$89

All unlimited plans →

Frequently asked questions

AI Prime Tech is an independent API gateway and is not affiliated with, endorsed by, or sponsored by Anthropic. “Claude” and “Claude Code” are trademarks of Anthropic. Claude Code features described here follow Anthropic’s public documentation at the time of writing and change frequently; prices and model lists on this page are read from this gateway’s live settings.