
agentic-browser-testing
Goal-driven E2E testing where a browser agent (Playwright MCP / computer-use) reads a natural-language goal and explores the app via the accessibility tree to assert outcomes — no pre-written script. Covers when intent-driven beats scripted, making agent runs repeatable and bounded (pinned model, temperature 0, seeded data, bounded steps, explicit success assertion, snapshot-not-pixel), cost/latency control, the accessibility-tree-first interaction model, CI gating, and graduating a stable run into a scripted Playwright test. Use when: "agentic browser test," "goal-driven browser test," "let an agent explore the app," "natural-language E2E," "browser agent smoke test," "Playwright MCP test." Not for: Writing/maintaining deterministic scripted Playwright tests — that is playwright-automation. Testing your product's OWN LLM features — that is ai-system-testing. Related: playwright-automation, ai-system-testing, exploratory-testing, test-reliability, qa-project-context.
- Installs
- 1.4K
- Last 24h
- +14
- Trending rank
- #7309
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/petrkindlmann/qa-skills --skill agentic-browser-testing- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads agentic-browser-testing automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Quick Route
| Situation | Go to |
|---|---|
| Stand up a goal-driven run from scratch | Discovery + references/setup.md |
| Decide agentic vs scripted for a given flow | Fit: Intent-Driven vs Scripted |
| Agent passes one run, fails the next | Repeatability |
| "How does it click without screenshots?" | Interaction Model |
| Runs are slow / burning tokens | Cost and Latency |
| Agent reports false success | Success Assertion (the Oracle) |
| Flow is stable — make it permanent | Graduation → references/graduation-and-ci.md |
| Block a merge on the goal | CI Gating → references/graduation-and-ci.md |
| Canvas / no accessibility tree | Canvas Fallback → references/graduation-and-ci.md |
Discovery Questions
First, check .agents/qa-project-context.md in the project root and skip anything it already
answers (stack, environments, seed/reset tooling, model access).
- Which flow, and how often does its UI change? Fast-changing/experimental UI favors intent-driven; a stable critical path (login) favors scripted. This decides the whole approach.
- Is there a seeded fixture and a way to reset state? Repeatable comparisons require controlled data and a per-run reset. If neither exists, that is step zero.
- Can you deep-link past auth to a seeded entry point? Re-driving login every run is the biggest avoidable cost; a seeded entry URL scopes the goal and cuts steps.
- What is the unambiguous success oracle? Specific account text, a
/dashboardURL, an order number — plus a forbidden state. "No error" is not an oracle. - Does the target render to canvas / WebGL? No accessibility tree means snapshot-first won't work; plan the vision fallback or instrument the canvas with ARIA.
- Which model and budget? Choose an available model version and enforce step, time and token budgets up front. Record the installed adapter and actual model returned by the service.
Core Principles
-
Choose intent-driven exploration where it helps. The agent reads a goal and chooses controls from the current accessibility tree. Compare its observed cost, latency and repeatability with scripted checks before using it for a critical path. Role-based scripted locators also survive many layout and CSS changes.
-
Control variance and measure repeatability. Pin supported model settings, reset the fixture, bound steps and wall time, and evaluate a separate oracle. Temperature zero and a pinned model reduce some variability; they do not guarantee identical navigation or verdicts. Run repeated healthy and broken controls before enabling a CI gate.
-
The oracle lives outside the agent. Never let the LLM self-grade "looks good." Success is a checkable assertion against the final
browser_snapshot— specific expected text, a URL, AND a forbidden-state negative check — evaluated by your harness, not the model. -
Accessibility tree first, pixels last.
browser_snapshotreturns roles, refs, and accessible names in a machine-readable form. Screenshots, pixel coordinates, vision, and OCR are a scoped last resort for canvas only, never the default. -
Graduation is the goal, not perpetual agent runs. Once a flow is stable, promote the run to a durable scripted
tests/*.spec.tswith role-based locators. An agent that has been green for two weeks should become a fast, free regression test — keep the agent for exploration, not for guarding a settled path.
Fit: Intent-Driven vs Scripted
The decision is per-flow, not per-project. Run risk-based-testing first if you need the
risk map; this table is the routing rule once you have it.
| Flow characteristic | Use | Why |
|---|---|---|
| Stable, high-frequency critical path (login, payment) | Scripted + pinned (playwright-automation) | Runs every PR with a maintained sequence and explicit assertions. |
| Fast-changing / experimental UI (a dashboard that churns weekly, a redesign in flight) | Agentic / intent-driven | Selectors would break constantly; a goal survives layout churn. |
| Hard-to-locate flow you can't reliably select | Agentic | The agent finds the control by role/name instead of you reverse-engineering a selector. |
| Exploratory smoke / "does the happy path still work at all" | Agentic | One NL goal covers a lot of ground without a maintained script. |
| Anything in CI that must never falsely pass | Scripted, OR agentic with a hard oracle | Non-determinism is a false-pass risk you must actively cap. |
The rule, stated plainly: keep stable critical paths scripted and pinned; point intent-driven agents at fast-changing UI and exploratory smoke. Do not move everything to the agent. Measure cost, latency and repeatability per flow; not every test should be agentic.
The Interaction Model (accessibility-tree-first)
Playwright MCP is not computer-use with screenshots and pixel coordinates. It is accessibility-tree-first:
browser_navigateto the seeded entry URL.browser_snapshotreturns the accessibility tree — each interactive element as arole, a currentref, and itsaccessible name(from ARIA/labels). References and snapshot size depend on the live page; refresh after a navigation or DOM change.- The agent picks an element by
refand callsbrowser_clickorbrowser_type. browser_wait_forwaits on text appearing/disappearing — never a fixed sleep.- Re-
browser_snapshotafter the DOM changes; assert against that tree.
Use semantic snapshots for ordinary controls because they expose roles and accessible
names directly. Measure token use and timing on the actual page. Use screenshots when
visual information matters; do not infer correctness from a screenshot alone.
browser_take_screenshot is for human evidence only, never as the assertion input.
See references/setup.md for the MCP registration, the full tool table, and the goal prompt.
Repeatability: making a run trustworthy in CI
A run that passes once and fails the next with no app change is not yet a test. The fix is never "just retry" or bumping temperature for "smarter" exploration — that adds variance. Pin the variables instead:
| Lever | Setting |
|---|---|
| Model | Pinned model id (e.g. claude-haiku-4-5-20251001), never latest |
| Sampling | Lowest supported sampling variance; record the setting, without claiming determinism |
| Data | Seeded fixture + reset/seed the database before every run |
| Scope | Bounded step budget (maxSteps), e.g. 18 — exceeding it FAILS, never auto-retries |
| Oracle | Independent checks against fresh application observations |
| Evidence | Assert on the accessibility tree, never a screenshot diff |
Avoid: temperature: 0.7 or 1 for exploration, retry-until-pass loops,
waitForTimeout sleeps, and screenshot-based assertions. Each one hides flakiness rather than
removing it. Adapter configuration examples are in references/setup.md; these fields need an actual host adapter to enforce them.
Success Assertion: the Oracle (where agents fail silently)
This is the sharpest failure mode: the agent reports success while stuck on the login page, because "page loaded / no error / looks good" was accepted as success and the LLM was allowed to self-grade. Force an explicit oracle the harness checks — never the agent.
For the goal "sign in as an existing user and confirm the dashboard shows the right account name":
SUCCESS (all must hold — assert against the final browser_snapshot):
- URL matches /dashboard
- Snapshot contains the specific expected account name text, e.g. "Acme Corp — Jane R."
NEGATIVE / forbidden state (fail fast if any is true):
- Still on a URL matching /login → FAIL
- Snapshot contains role="alert" with "invalid credentials" → FAIL
VERDICT: a project-owned oracle executes these checks; the evidence gate emits passed:true only after fresh, complete checks. The LLM does not decide.
The positive checks (specific account name + /dashboard URL) prove where it landed; the
negative check (must NOT be on the login page) is what kills the false pass. "No error,"
"didn't crash," "screenshot looks correct," and "trust the agent" are not success criteria.
Cost and Latency
Measure agent latency and cost against the scripted alternative. Model round trips can dominate a small browser flow. Control unnecessary work with explicit budgets:
- Step budget — keep
maxStepslow and enforced; fewer round-trips, less drift. - Model selection — use measured task accuracy, latency and cost to choose an available model. Pin the model version where the provider supports it.
- Prompt caching — cache the static system prompt, tool schemas, and goal; they repeat every run.
- Scope via a seeded entry point — one narrow goal per run, deep-linked past login instead of re-driving it each time.
- Snapshot size — scope snapshots to the relevant region where supported. Measure payload size; large DOMs can make text snapshots expensive too.
Backwards moves to reject: "use the biggest model for every step," "raise the step
limit," "screenshot every step," and running with no budget at all. See references/setup.md.
Graduation and CI Gating
Promote a stabilized goal into a durable scripted test, and gate merges on the verdict. Both
are detailed in references/graduation-and-ci.md; the essentials:
- Graduate with Playwright Test Agents (planner / generator / healer, shipped in
Playwright v1.56.0).
npx playwright init-agents --loop=claude. The planner writes a Markdown test plan tospecs/<flow>.md; the generator turns it intotests/<flow>.spec.tswith role-based locators (getByRole,getByLabel,getByText) verified against the live DOM; the healer repairs broken locators. This is the promotion path — not "keep running it as an agent," not recorded clicks, notpage.locator('xpath=...'), not data-testid-only. - Gate CI with
scripts/agent-result-gate.mjsfrom a full QA Skills checkout. It runs a reviewed oracle command and requires typed, nonempty evidence for the exact run, target and build.failedandblockedboth exit nonzero. The host agent adapter must separately enforce step/time budgets; a model-produced{"passed": true}cannot pass this gate. - Canvas with no accessibility tree: prefer instrumenting the canvas with ARIA; as a scoped
last resort enable
--caps=visionto unlockbrowser_mouse_click_xyfor that flow only.browser_snapshotwill not work on a raw canvas, but don't make coordinates the default and don't abandon agentic testing.
Migrating a brittle script to a goal (honest tradeoffs)
Converting an 80-line script that re-types login and walks 6 hardcoded steps into a single NL goal with an explicit success assertion is a real win for a churning flow — but state the downsides honestly:
- Non-determinism / false-pass risk — the run could pass falsely; that's why the hard oracle and the negative check are non-negotiable.
- Cost/latency — measure both; enforce a step budget, wall-clock limit and seeded entry point.
- Not every test should be agentic — keep stable paths scripted, and plan to graduate this one back to a scripted test once it stabilizes.
Reject the over-promise: it is not "strictly better with no downsides," do not "migrate everything," and never drop the assertions to make it pass.
Anti-Patterns
1. Reflexively writing a scripted Playwright test
"Browser test" pattern-matches to codegen, so the default is page.goto / page.locator /
await expect(page...) / hunting data-testid. That misses the entire point. A goal-driven
agent reads NL intent and explores via browser_snapshot — no pre-written selectors.
2. "Use the agent for everything"
Agent exploration has variable cost, latency and behavior. Stable critical paths (login) stay scripted and pinned; intent-driven wins on fast-changing UI. Never "always use the agent" or "agents replace all scripted tests."
3. Fixing flakiness with retries or higher temperature
"Just retry" and bumping temperature for "smarter" exploration both add variance. The real levers are temperature 0, a pinned model, seeded data, a bounded step budget, and an explicit verdict.
4. Assuming computer-use = screenshots + pixel coordinates
Playwright MCP is accessibility-tree-first. Defaulting to vision, screenshots, OCR, or
mouse_click_xy is slower, costlier, and flakier. Pixels are a canvas-only last resort.
5. "No error = success" (the false pass)
Accepting "page loaded / didn't crash / looks good" and letting the LLM self-grade is exactly why the agent reports success while stuck on login. Require specific expected text, a URL, and a forbidden-state negative check, evaluated by the harness.
6. Bigger model / more steps to go faster
Increasing model size or step limits is not evidence of reliability. Compare actual results under the same task and fixture, then select budgets and a model from that evidence.
7. Running an agent forever instead of graduating
A goal green for two weeks on a now-stable flow should become a scripted tests/*.spec.ts via
Playwright Test Agents. "Keep running it as an agent," recording clicks, and xpath locators are
all wrong promotions.
8. Prose verdict in CI
Returning a paragraph for a human to read, or continue-on-error: true, lets a failed goal
merge. The run must exit non-zero on failure with a machine-readable boolean.
Done When
- Goal prompt exists as natural-language intent (no
page.locator/page.goto/data-testidin the goal) with a START seeded entry URL. - An explicit success oracle is defined: specific expected text AND a URL check AND a
forbidden-state negative check, asserted against
browser_snapshot— not a screenshot. - Run config pins a supported model version and sampling settings, a
maxStepsbudget, and a seed; nowaitForTimeout, no retry-until-pass. - Interaction is snapshot-first:
browser_navigate/browser_snapshot/browser_click/browser_type/browser_wait_for; screenshots used only for evidence. - The adapter emits a typed activity record; the independent gate executes the approved
oracle and writes
gate-result.json. Missing or blocked checks fail CI, as do failed ones. - CI seeds/resets ephemeral state per run and enforces a step budget and a timeout cap.
- A graduation trigger is recorded (e.g. "green for 2 weeks → run
init-agents, generatetests/<flow>.spec.tswithgetByRolelocators"). - If any target is canvas/WebGL, the vision fallback (
--caps=vision+browser_mouse_click_xy) is scoped to that flow only, or the canvas is instrumented with ARIA.
Related Skills
- playwright-automation — Writing and maintaining deterministic scripted Playwright tests and Page Objects. Go there to author the durable test; this skill graduates an agent run into one.
- ai-system-testing — Testing your product's OWN LLM/AI features (prompt regression, model output quality). This skill tests any app using an agent; it does not test your AI feature.
- exploratory-testing — Human SBTM exploration and bug hunting. The agentic smoke goal is the automated cousin; use exploratory-testing for charter-driven manual sessions.
- test-reliability — Self-healing locators and quarantine for scripted flaky tests at runtime. Complements the determinism levers here once a test has graduated.
- qa-project-context — The universal dependency; supplies stack, environments, seed/reset tooling, and model access that every question above depends on.
Reference Files (in references/)
- setup.md — Playwright MCP registration (
.mcp.json), the snapshot tool table, the natural-language goal prompt with success/negative assertions, the determinism harness config (pinned model, temperature 0, maxSteps, seed, prompt cache), and cost/latency levers. - graduation-and-ci.md — Playwright Test Agents promotion pipeline (planner →
specs/*.md, generator →tests/*.spec.tswith role-based locators, healer), the GitHub Actions gating flow using the executable independent evidence gate, and the canvas--caps=visionfallback. - gate-contract.md — exact gate config, adapter activity record and oracle evidence schema, plus a bounded HTTP example. Requires a project-owned host adapter; no model runner is bundled.
FAQ
What does the agentic-browser-testing skill do?
Goal-driven E2E testing where a browser agent (Playwright MCP / computer-use) reads a natural-language goal and explores the app via the accessibility tree to assert outcomes — no pre-written script. Covers when intent-driven beats scripted, making agent runs repeatable and bounded (pinned model, temperature 0, seeded data, bounded steps, explicit success assertion, snapshot-not-pixel), cost/latency control, the accessibility-tree-first interaction model, CI gating, and graduating a stable run into a scripted Playwright test. Use when: "agentic browser test," "goal-driven browser test," "let an agent explore the app," "natural-language E2E," "browser agent smoke test," "Playwright MCP test." Not for: Writing/maintaining deterministic scripted Playwright tests — that is playwright-automation. Testing your product's OWN LLM features — that is ai-system-testing. Related: playwright-automation, ai-system-testing, exploratory-testing, test-reliability, qa-project-context.
How do I install agentic-browser-testing?
Run npx skills add https://github.com/petrkindlmann/qa-skills --skill agentic-browser-testing in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/agentic-browser-testing/ (personal) or .claude/skills/agentic-browser-testing/ (project).
Which AI agents can use agentic-browser-testing?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is agentic-browser-testing safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains agentic-browser-testing?
It is published by petrkindlmann in petrkindlmann/qa-skills. It has 1,374 recorded installs.
More from petrkindlmann/qa-skills
playwright-automation
petrkindlmann/qa-skills
Write production-grade Playwright tests in TypeScript: Page Object Model, fixtures, auto-waiting, user-facing locators, parallel execution, CI integration, sharding, and installed-version checks. Includes an explicit "do not" list for AI agents. Use when: "Playwright," "write E2E test," "page object," "new Playwright suite," "Playwright config." Not for: fixing one flaky test at runtime — use test-reliability. Not for: bulk regenerating selectors after a UI refactor — use selector-drift-recovery. Not for: visual baseline creation/management — use visual-testing. Not for: deep WCAG/axe audits — use accessibility-testing. Related: visual-testing, ci-cd-integration, api-testing, test-reliability, selector-drift-recovery, accessibility-testing.
exploratory-testing
petrkindlmann/qa-skills
Design and execute structured exploratory testing sessions. Covers Session-Based Test Management (SBTM), charter writing, heuristic-based exploration (HICCUPS, FEW HICCUPS), bug discovery patterns, note-taking templates, and conversion of findings to automated tests. Use when: "exploratory testing," "SBTM," "manual testing," "bug hunting," "test charter," "heuristic testing." Not for: an AI browser agent autonomously exploring the app from a natural-language goal — use agentic-browser-testing. Not for: testing your product's own AI/LLM features — use ai-system-testing. Related: test-planning, ai-bug-triage, risk-based-testing, agentic-browser-testing.
test-strategy
petrkindlmann/qa-skills
Produce a multi-quarter QA strategy document. Covers scope, risk-based prioritization, test levels (unit/integration/E2E), pyramid analysis, entry/exit criteria, quality KPIs, tool selection rationale, CI scaling levers, and timeline planning. Output is an actionable strategy document, not a shelf document. Use when: "test strategy," "QA strategy doc," "testing approach," "QA roadmap," "multi-quarter QA direction." Not for: a single-sprint or single-release plan — use test-planning. Not for: identifying which areas carry the most risk — use risk-based-testing first. Related: risk-based-testing, qa-metrics, release-readiness, test-planning, test-reliability.
test-planning
petrkindlmann/qa-skills
Build a single sprint or release test plan. Covers feature decomposition into testable scenarios, requirements-to-test coverage mapping, effort estimation by test type, prioritization matrices (risk × effort), resource allocation, and scheduling with buffers. Use when: "sprint test plan," "release test plan," "what to test this sprint," "test estimation," "coverage mapping." Not for: multi-quarter strategy — use test-strategy. Not for: ranking areas by risk — use risk-based-testing. Not for: the go/no-go decision itself — use release-readiness. Related: test-strategy, risk-based-testing, release-readiness.
qa-project-context
petrkindlmann/qa-skills
Create and fill .agents/qa-project-context.md with the project's tech stack, test frameworks, CI/CD pipeline, environments, quality goals, risk areas, team structure, and conventions. This is the one file every other QA skill reads first, so they skip redundant discovery and give context-aware advice. Use when: "set up QA context," "configure testing," "initialize project," first use of any QA skill. Not for: bootstrapping a brand-new project's QA end-to-end — use qa-start (which calls this skill as its first step). Related: qa-start, risk-based-testing, test-strategy, qa-metrics, playwright-automation.
risk-based-testing
petrkindlmann/qa-skills
Produce a risk matrix or heatmap that quantifies what could break by business impact × probability, runs failure mode analysis on the top items, and maps test coverage to risk zones. Includes stakeholder interview frameworks and continuous reassessment. Run this BEFORE test-strategy or test-planning. Use when: "risk assessment," "risk matrix," "risk heatmap," "what could break," "critical paths," "failure modes," "where to focus testing." Not for: multi-quarter QA direction — use test-strategy. Not for: a single sprint/release test plan — use test-planning. Not for: hands-on session-based bug hunting — use exploratory-testing. Related: test-strategy, test-planning, release-readiness, qa-metrics.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work