How to QA an App with Claude Code

What It Means to QA an App With Claude Code

You connect a browser- or device-automation MCP server to Claude Code, then describe the test you want in plain English. The agent calls that server's tools to drive the real app, clicking, typing, and navigating, checks what happened, and reports back with screenshots. There is no selector-heavy script to write or maintain.

Two MCP servers do most of the work in 2026. For the web, Playwright MCP from Microsoft is the common choice. For iOS, Android, and web from a single tool, Watchr is purpose-built; we cover it in detail in the Watchr deep dive. This guide stays vendor-neutral and focuses on the workflow, which is the part that survives whichever server you pick.

Before You Start

• Claude Code 1.0 or newer. Check with claude --version. If you do not have it, install it with npm install -g @anthropic-ai/claude-code.
• For web tests: Node 20 or newer. Older versions break the driver Playwright relies on.
• For mobile tests: a running iOS Simulator or Android emulator (or a connected device), and Python 3.11 to 3.13 if you use Watchr through uvx.
• An app to point it at: a local dev URL such as localhost:3000, or a built mobile app on the simulator.

The Short Version

If you have done this before, here is the whole thing. The sections below explain each part.

# Web testing — Playwright MCP (Microsoft):
claude mcp add playwright npx @playwright/mcp@latest

# Mobile + web — Watchr:
claude mcp add --scope user watchr -- uvx --python 3.12 --upgrade watchr-mcp

# Then just talk to Claude Code:
"Open localhost:3000, sign up with a test account, and tell me what breaks."

Step 1: Connect a Testing MCP Server

Registering an MCP server is one command. For web testing, add Playwright MCP:

claude mcp add playwright npx @playwright/mcp@latest

For mobile plus web from one server, add Watchr instead (or as well, you can run both):

claude mcp add --scope user watchr -- uvx --python 3.12 --upgrade watchr-mcp

The --scope user flag makes the server available across all your projects; use --scope project to commit the config and share it with your team. New to MCP entirely? Our MCP setup walkthrough covers the basics, and the Playwright stealth-Chromium guide is useful if you need the browser to behave like a real one.

Step 2: Run Your First Test in Plain English

Open Claude Code in your project and describe the test. The single biggest factor in getting a useful result is specificity. Give the agent a target, a goal, and a way to prove the outcome.

# Be specific. Give the agent a target, a goal, and how to prove it.

# Vague (you will get a vague answer):
"Test my app."

# Good:
"Open http://localhost:3000. Sign up with email [email protected],
add the first product to the cart, and complete checkout with Stripe
test card 4242 4242 4242 4242. Screenshot each step. If anything
errors or looks wrong, stop and tell me exactly where."

The agent will open the app, perform the steps, capture screenshots, and tell you where it stopped. If it claims success, ask it to prove the result, for example that the order confirmation number is visible on screen. That one habit catches most false passes.

Step 3: Decide What to Test

A QA agent is only as good as the briefs you give it. Work through these categories rather than asking it to vaguely test everything. Each row is a real prompt you can paste.

Happy paths are the easy half. Most real bugs hide in bad input, empty states, and the moment the network drops, so spend your prompts there.

Step 4: Make It Repeatable

A one-off test is handy. A repeatable one changes how you ship. Three habits get you there:

• Keep your test briefs in the repo. Save the prompts that matter as a short markdown checklist so anyone (or any agent) can re-run them.
• Test the diff before each PR. “Test the flow I just changed and tell me what broke” is the highest-value prompt you will write all week.
• Set visual-regression baselines. Capture a known-good screenshot once, then have the agent diff against it on later runs so layout regressions surface on their own.

Step 5: Decide What Belongs in CI

Be honest about what an agent is good at here. Agent-driven testing is exploratory and non-deterministic, so it is a poor fit for the check that blocks a merge. Keep your unit and integration tests as the gate. Use the agent for the things deterministic tests miss: a pre-merge smoke pass on the changed flow, or a nightly exploratory crawl that files issues when it finds something.

The strongest pattern is to let the agent do the discovery and then hand you a deterministic artifact. Ask it to turn a passing flow into a Playwright spec; review that file and commit it. Playwright MCP added self-healing in 2026, which repairs broken selectors and timing, so those generated tests are less brittle than they used to be. Now the agent has effectively written part of your real test suite.

When It Goes Wrong

Where Agent QA Falls Short

It is worth knowing the edges before you lean on this. An agent will not replace your deterministic test suite, and it should not. It can be confidently wrong, which is why screenshots and explicit assertions matter. Runs cost tokens, so an unscoped “test the whole app” can get expensive. And anything touching security, privacy, or compliance still needs a human sign-off, not an agent's summary. Used for what it is good at, exploratory coverage and fast pre-merge checks, it earns its place. Treated as a full replacement for QA, it will let real bugs through.

This is the same lesson the broader agent ecosystem keeps learning: agents are powerful when they act inside clear boundaries, whether that boundary is a test scope or, as in agentic payments, a spending limit.

FAQ

Sources

• Playwright: official Playwright MCP docs
• Simon Willison: using Playwright MCP with Claude Code
• Testomat: Playwright MCP and Claude Code
• TestQuality: Claude Code with Playwright MCP
• Watchr: QA agent for iOS, Android, and web