Browser Automation and QA

Browser automation is a family of task shapes with a new default: use Browser Testing Skills for agent-driven browser work, Playwright for committed regression tests, Browserbase for reusable cloud workflows, and Chrome DevTools/browser-harness only for specialist inspection paths. Source: User request, 2026-06-27; User request, 2026-07-04; Skill Resolver

When To Use This

Use this page when a task says "test the UI," "open the site," "debug localhost," "use Browserbase," "run browser-use," or "check what the page does." These are adjacent but not interchangeable. Source: Skill Resolver, 2026-06-27

Decision Matrix

Task Use first Why
Agent-driven browsing, scraping, forms, screenshots, UI QA Browser Testing Skills Agent-native commands, compact snapshots, sessions, Chrome profiles, diffs
Deterministic regression Browser Testing Skills Reviewable and CI-friendly test artifact
Visual/responsive QA Browser Testing Skills Real rendered evidence plus snapshots/diffs/perf; escalate only when needed
Text-only builder needs visual judge Browser Testing Skills qa or another vision reviewer Multimodal evaluation with score/evidence
Reusable website workflow Browserbase Ecosystem / Browserbase Browse.sh (Open Web Catalog) Learn once, replay later
Undocumented API discovery Browser to API candidate route Capture observed traffic, generate a spec, review/redact before use
Existing logged-in browser Browser Testing Skills with Chrome profile / auto-connect Uses the live or persisted session
Computed styles / box model deep dive Chrome DevTools MCP Specialist inspection after agent-browser finds the issue
Library-specific Browser Use task Browser Testing Skills Only when that framework is named or required

Core Model

Separate exploration from regression. Exploration discovers behavior and visual bugs. Regression captures the important behavior as a deterministic test. A good agent loop uses both and promotes repeated browser work into a skill or test. Source: Browser Harness - Self-Healing Browser Automation; Browser Testing Skills

Tool And Skill Routing

Use Browser Testing Skills for the first pass on browser work: token-efficient snapshots, screenshots, React/perf checks, ad-hoc browsing, scraping, form fills, logged-in Chrome flows, and localhost UI checks. Use Browser Testing Skills for codified browser tests after the behavior should become a reviewable gate. Use Browserbase Ecosystem when remote sessions or site skills matter. Use Local Web Verification when the main question is "does my localhost app actually work?" Source: Skill Resolver, 2026-06-27; User request, 2026-07-04

Browser Use's upstream qa skill is the useful exception to "Browser Use only when named": it demonstrates an evaluator loop where a website gets a 1-5 score with evidence from a real browser. Use it when a text-only coding/model agent needs a multimodal QA subagent, or when Browser Use cloud is already the browser substrate. Do not replace deterministic Playwright tests with a subjective score. Source: Browser Use docs, 2026-06-30

browser-trace -> Browser to API is a separate route for API-discovery from an observed web flow. It belongs after an explicit human/legal/safety judgment, not inside routine QA. The generated OpenAPI file is only as complete and safe as the captured flow, and trace/report artifacts require redaction because they can contain auth material and private user data. Source: GitHub browserbase/skills, 2026-06-30

Failure Modes

  • Using Browserbase for a test that should become Playwright.
  • Calling any browser task "QA" without checking console/network/rendered state.
  • Reaching for Playwright or Puppeteer for ordinary agent browsing instead of agent-browser.
  • Treating browser automation as agent search or docs lookup.
  • Treating observed private or authenticated traffic as a public API contract.
  • Leaving screenshots or browser artifacts unmanaged after verification.

Evidence And Timeline

The current routing stack distinguishes Browserbase, browser-use, Playwright, agent-browser, browser-harness, and Chrome DevTools. The generated packs should load this page before pulling every small browser tool page. Source: Capability Routing Map; Wiki Capsules And Agent Doc Packs

Concept Position

Field Value
Concept family Agent harness and runtime primitives
Concept owned Browser automation is a family of task shapes, not one tool: use Playwright for repeatable tests, browser-harness or agent-browser for visu...
Category map Concept System Map

Timeline

  • 2026-07-01 | Concepts category refresh added this page to the Agent harness and runtime primitives family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: Browser automation is a family of task shapes, not one tool: use Playwright for repeatable tests, browser-harness or agent-browser for visu... Source: User request, 2026-07-01
  • 2026-06-30 | Added Browser Use qa as the explicit text-only-builder/multimodal-reviewer route after deep-reviewing the GLM 5.2 + Browser Use QA bookmark and upstream skill docs. Source: X/@browser_use, 2026-06-20
  • 2026-06-30 | Added Browser to API as the API-discovery route for observed traffic, with redaction and source-review gates before any generated client/spec leaves the local run. Source: X/@derekmeegan, 2026-05-13
  • 2026-06-27 | Canonical cluster page created to stop browser automation, browser QA, local verification, and agent search from collapsing into one bucket. Source: User request, 2026-06-27