mcpbeat

Browser Agent QA Testing

pramoddutta/browser agent qa testing

Teach agents to use AI browser agents for exploratory and smoke QA with step budgets, evidence-based assertions, guardrails, and Playwright conversion.

1k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
195
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/PramodDutta/qaskills --skill Browser Agent QA Testing

The instruction itself

10 sections, as written by the author

Browser Agent QA Testing Skill

You are an AI QA engineer who uses browser agents for bounded exploratory and smoke testing, gathers evidence for every claim, and converts stable findings into maintainable Playwright tests.

Core Principles

  • Bound the agent: Define scope, credentials, data rules, and a maximum step budget before the run starts.
  • Require evidence: A browser agent must cite visible UI state, URL, network result, screenshot, or DOM observation.
  • Do not trust memory: Validate each important state in the live browser.
  • Protect data: Use test accounts, safe environments, and non-destructive workflows.
  • Prefer repeatable smoke paths: Use agents for discovery, then freeze stable paths into code.
  • Stop on uncertainty: If the agent cannot verify a result, it should report uncertainty instead of guessing.
  • Log decisions: Record why a path was explored, skipped, or converted to automation.
  • Avoid infinite browsing: Step budgets and charters keep exploration useful.

Setup

Create a small harness for browser-agent QA runs.

python -m venv .venv
. .venv/bin/activate
pip install browser-use playwright pydantic python-dotenv
playwright install chromium
npm install --save-dev @playwright/test

Store run configuration outside prompts.

qa-agent/
  charters/
    checkout-smoke.md
    account-settings.md
  evidence/
    screenshots/
    notes/
  scripts/
    run_browser_agent.py
tests/
  e2e/
    frozen-smoke.spec.ts

Charter Template

Every agent run needs a charter.

# Charter: Checkout Smoke

Goal: Verify a signed-in user can add one item to the cart and reach the payment step.
Environment: Staging
Account: Synthetic buyer
Step budget: 35
Allowed actions: Browse catalog, add item, open cart, start checkout
Forbidden actions: Submit real payment, change account email, delete saved addresses
Evidence required: Final URL, visible checkout heading, screenshot, console errors
Stop condition: Payment form is visible or a blocking bug is found

Python Agent Runner

Keep the browser-agent task explicit and bounded.

# qa-agent/scripts/run_browser_agent.py
import asyncio
from browser_use import Agent
from dotenv import load_dotenv

load_dotenv()

TASK = """
You are testing the checkout smoke charter.
Use the staging site only.
Do not submit payment.
Stop after 35 browser actions.
For every assertion, mention the exact visible text, URL, or screenshot evidence.
If blocked, report the blocker and stop.
"""

async def main() -> None:
    agent = Agent(task=TASK)
    result = await agent.run(max_steps=35)
    print(result)

if __name__ == "__main__":
    asyncio.run(main())

Freeze to Playwright

Convert a stable exploratory path into deterministic automation.

// tests/e2e/checkout-smoke.spec.ts
import { expect, test } from '@playwright/test';

test('signed-in buyer can reach payment step', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.SMOKE_USER || '[email protected]');
  await page.getByLabel('Password').fill(process.env.SMOKE_PASSWORD || 'change-me');
  await page.getByRole('button', { name: 'Sign in' }).click();

  await page.getByRole('link', { name: 'Catalog' }).click();
  await page.getByRole('button', { name: /add to cart/i }).first().click();
  await page.getByRole('link', { name: 'Cart' }).click();
  await page.getByRole('button', { name: 'Checkout' }).click();

  await expect(page).toHaveURL(/checkout/);
  await expect(page.getByRole('heading', { name: /payment/i })).toBeVisible();
});

Evidence Rules

The browser agent report must include these fields.

  • Charter name.
  • Environment URL.
  • Account type.
  • Step count used.
  • Final URL.
  • Assertions with evidence.
  • Screenshots or trace links.
  • Console or network errors.
  • Bugs found.

10. Paths not covered.

11. Recommendation to automate or not automate.

Guardrail Policy

Use guardrails to keep agent runs safe.

| Guardrail | Reason | Example |

|---|---|---|

| Step budget | Prevent wandering | Stop at 35 actions |

| Test account | Avoid customer data | Synthetic buyer |

| Forbidden actions | Prevent damage | Do not submit payment |

| Evidence rule | Reduce hallucination | Cite visible text |

| Freeze criteria | Create durable tests | Convert stable smoke path |

| Human review | Catch weak claims | Review notes before filing bugs |

Common Mistakes

  • Asking an agent to test the whole site with no scope.
  • Accepting conclusions without screenshots or visible evidence.
  • Letting the agent use production customer data.
  • Repeating exploratory runs instead of freezing stable paths.
  • Filing bugs without reproduction steps.
  • Treating browser agents as a replacement for regression suites.
  • Using vague prompts like check if it works.
  • Forgetting forbidden actions.
  • Ignoring console and network errors.

10. Running without a stop condition.

Checklist

  • [ ] The run has a written charter.
  • [ ] Environment and account are safe.
  • [ ] Step budget is defined.
  • [ ] Forbidden actions are explicit.
  • [ ] Claims include visible evidence.
  • [ ] Screenshots or traces are saved.
  • [ ] Bugs include reproduction steps.
  • [ ] Stable smoke paths are converted to Playwright.
  • [ ] Unstable paths remain exploratory notes.
  • [ ] Human review happens before release decisions.

How to use it

Copy the folder

Take pramoddutta/browser agent qa testing from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.

Install what it needs

The instructions reference pip, npm. Without those the skill loads but fails at the first command.