mcpField
B
browser-qa

browser-qa

github.com/angusfretwellTesting & quality171 installsUpdated 4d ago
Repository

About browser-qa

A browser-based QA skill for checking a running app against a specified change and its originating spec. It uses runtime observation as evidence and produces a verdict with screenshot and video references.

Key features

  1. 01Identify test scope and spec
  2. 02Drive app flows end to end
  3. 03Probe relevant edge cases
  4. 04Report pass or fail
  5. 05Close browser sessions and app processes

Use cases

  1. 01Verify a branch against its feature spec
  2. 02Exercise changed flows in a running app
  3. 03Capture evidence for a QA report

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/angusfretwell/skills --skill browser-qa

After installing, type/browser-qain Claude Code to confirm it loaded.

Details

From the project README

Verification is runtime observation: what you capture from the running app is the evidence; tests and typechecks are CI's output, not yours.

Steps

1. Establish what's under test

Whatever the user said is the scope (a commit SHA, branch name, tag, main, HEAD~5). If they didn't specify one, ask for it.

2. Identify the spec source

Look for the originating spec, in this order:

  1. Issue references in the commit messages (#123, Closes #45, GitLab !67), fetched via the workflow in docs/agents/issue-tracker.md.
  2. A path the user passed as an argument.
  3. A spec file under docs/, specs/, or .scratch/ matching the branch name or feature.
  4. If nothing is found, ask the user where the spec is.
3. Drive

Refuse if agent-browser isn't installed: stop and tell the user. Invoke the run skill and get the URL the app is serving on; refuse likewise if the app won't run.

Invoke the agent-browser skill and load its dogfood workflow with agent-browser skills get dogfood --full; --full inlines the report template and edge-case checklist. Follow it against the URL, with two changes:

  • Scope to the diff, not the full app. The diff is the only code you read, and only to list the flows it affects.
  • The report is your reply, not a file, citing screenshots and videos by absolute path.

Drive every flow the change affects end-to-end, then pick probes from the edge-case checklist that fit the change.

When the brief hands you fixtures, test data already set up, drive the flows with them and build only what they lack.

4. Verdict

Open the report with a verdict on the first line: pass or fail. Fail on any issue that breaks the specified behaviour or fails a probe. There is no partial pass: anything short is a fail, with the passing parts noted.

Then tear down what you started: close each browser session you opened with agent-browser --session <name> close, and stop any app process you launched, leaving one you found running. Each session holds a headless Chrome until it's closed. Teardown runs on every exit, refusals included.

Done when the report opens on its verdict and teardown is complete.

Comments

Markdown supported