21.2Scenario-Based Recommendations

Scenario 1: New Startup, Building From Scratch

Context: Small team, modern SPA, CI/CD via GitHub Actions, a coding agent (Claude Code, Cursor) already in the workflow.

Recommendation: Playwright CLI + skills, with Test Agents for generation

Why:

• One install (playwright-cli install --skills), zero framework code to start
• The same agent that writes your application code drives your tests — shared context, and the CLI path keeps that context affordable
• init-agents scaffolds planner/generator/healer for your agent runtime
• Grows naturally into a reviewed specs/ + tests/ structure

Scenario 2: Enterprise with Existing Selenium Suite

Context: Large team, legacy application, 2000+ existing Selenium tests, migrating to AI-assisted QA.

Recommendation: Selenium 4.x (existing) + Playwright CLI skill (new tests)

Why:

• Don't rewrite 2000 tests — maintain the existing Selenium suite
• New tests go agent-driven on the Playwright stack
• Both worlds converge on WebDriver BiDi over time (low-level in Selenium 4 today, high-level in the eventual Selenium 5)
• Gradual migration as old tests naturally need updates

Scenario 3: Accessibility-First Product

Context: Government or healthcare app with WCAG compliance requirements.

Recommendation: Playwright (CLI or MCP — both expose accessibility structure) + dedicated a11y tooling

Why:

• The YAML snapshots are accessibility-tree summaries — roles and accessible names are the primary addressing scheme, so a11y problems surface constantly during normal test runs
• For deep WCAG audits, the agent analyzes ARIA roles, labels, and structure semantically; pair with axe-style rule engines for the mechanical checks
• Traces give you the audit evidence trail compliance teams ask for

Scenario 4: Complex B2B Dashboard

Context: Data-heavy application with charts, tables, drag-and-drop, custom components.

Recommendation: Playwright CLI (standard flows) + Stagehand or browser-use (the gnarly parts)

Why:

• Standard flows (login, navigation, CRUD) run cheap on the CLI path
• Custom canvas/chart components may defeat structural snapshots — intent APIs (Stagehand) or vision (browser-use) earn their extra cost exactly here
• Higher per-interaction cost is justified for the 10% of UI that's genuinely hard

Scenario 5: CI-Only Test Runner (No Human Involvement)

Context: Fully automated pipeline, tests run on every push, no human reviews failures in real-time.

Recommendation: Playwright CLI skill, fresh sessions, healer as follow-up job

Why:

• Lowest token cost per run of the agent-driven options
• Failure artifacts (screenshots, snapshots, traces with network capture) collected automatically
• The healer agent triages failures: patch proposals arrive as PRs; "app actually broken" verdicts page a human
• JUnit XML for CI dashboard integration