The official Playwright MCP server lets an LLM drive a live browser through accessibility-tree snapshots — no screenshots, no pixel guessing. Directed well, it becomes a tireless exploratory tester, a repro machine for vague bug reports, and a drafting hand for new specs, while you keep the tester's judgment.
Tier: Core · Workflow area: Agentic test stack & self-healing
This playbook wires Playwright MCP into your assistant and runs three high-value session types — exploratory sweep, bug reproduction, and test drafting — each with a human verification step before anything is believed or committed.
claude mcp add playwright -- npx @playwright/mcp@latest.Verify the wiring with a trivial errand. "Open http://localhost:3000, tell me the page title and the main navigation items." The reply should quote real DOM content — this confirms snapshots flow before you invest in a session.
Exploratory sweep — charter first, then direct. Give the model a charter, a persona, and reporting rules:
You are exploring the signup flow at http://localhost:3000 for 20 minutes.
Charter: hunt input-validation and error-recovery problems.
Try: emails with unicode and plus-addressing, a 300-char name, double-clicking
submit, going Back mid-flow, expired-session resubmission.
Report each anomaly as: STEPS | EXPECTED | ACTUAL | SEVERITY-GUESS.
Do not mark anything a bug without stating what you expected and why.
Steer live ("interesting — push harder on the Back-button case") exactly as you would pair with a junior tester. Sample finding you should expect back:
ANOMALY 3
STEPS: entered "José+test@exämple.com", submitted, corrected to plain ASCII, resubmitted
EXPECTED: second submit succeeds
ACTUAL: button disabled permanently; page reload required
SEVERITY-GUESS: medium — recoverable but user-visible dead end
Verify every finding yourself. Reproduce each anomaly by hand or replay its steps before it goes anywhere near a tracker. The model misreads app intent regularly — an unfamiliar-but-correct behavior is not a bug. Your session sheet records which findings survived verification.
Repro session — turn a vague ticket into steps. Paste the ticket and constrain the search:
Bug report: "cart occasionally empties after login". Try to reproduce on
http://staging.example.test with user qa-cart-01.
Vary one factor at a time: add-to-cart before vs after login, session idle 0/5/30 min,
second tab logged into the same account, login via email vs SSO button.
After each attempt report: variation | cart state | evidence (exact DOM text).
Stop at first reliable repro and give me the minimal step list.
The one-factor-at-a-time instruction matters — it converts flailing into an experiment design, and the minimal repro is what makes the eventual defect report filed-quality.
Draft specs from the live session. Once a flow or repro is understood, have the model write the test from what it actually saw:
Write a Playwright spec for the recovered-submit bug above. Use getByRole/getByLabel
locators taken from the page you just drove — do not invent selectors. Assert the
user-visible outcome (button re-enabled, form submittable), not internal state.
Then prove the draft honestly: run it, and confirm it fails on the broken build and passes once the bug is fixed (or vice versa for regression specs).
npx playwright test tests/signup-resubmit.spec.ts --repeat-each=3
Close the session with a debrief. Ask for a summary against the charter: areas covered, areas not reached, verified findings, and what a follow-up session should target. File verified bugs through your defect-report workflow.
MCP gives the model hands, not judgment. Every finding is a claim until you reproduce it; every drafted spec is a guess until it fails on the broken build. The charter, the steering, and the verification pass are where the QA actually happens.
--headless off) while you are learning to steer — watching the browser move teaches you what the model misunderstands.An MCP session streams page content — DOM text, user data on screen — to the model provider. On client work, treat that as data egress: use only client-approved assistants, run against synthetic-data test environments, and keep client production URLs and real customer records out of sessions entirely. Where policy demands local-only, host the model via Ollama with an MCP-capable client; steering quality drops, so tighten charters and expect more verification work.
Save your best session prompts — the signup-abuse charter, the one-factor repro template — into the team prompt library. A well-worded charter is reusable test IP; the session it drives is disposable.