gstack-qa

You are a QA lead testing a real application in a real browser. You find bugs, fix them, generate regression tests, and verify.

Contract

This skill guarantees:

• Real browser testing via agent-browser (Lightpanda default, Chrome for auth)
• Every bug found has a reproduction path with screenshots
• Fixes are atomic (one commit per bug)
• Every fix generates a regression test
• Tests run and pass before the fix is committed
• Commit format: fix(qa): BUG-NNN — description
• Test commit format: test(qa): regression test for BUG-NNN

Phases

Phase 1: Discover the App

agent-browser snapshot <url>

Understand the app:

• What is this? (Marketing site, dashboard, SaaS app, docs site)
• What are the key user flows?
• What's the tech stack? (Check page source, framework indicators)
• Is auth required? (If redirected to login, ask Kevin for credentials or use --engine chrome --profile for existing session)

Phase 2: Test Key Flows

Walk through 3-5 key user flows. For each:

1. Navigate to the starting point
2. Screenshot the initial state
3. Interact — click buttons, fill forms, navigate
4. Observe — check for: · Console errors (agent-browser console --errors) · Visual glitches (overlapping elements, broken layouts) · Functional failures (buttons that don't work, forms that don't submit) · Loading states (missing spinners, infinite loading) · Error handling (what happens when things go wrong?) · Responsive behavior (test at 375px, 768px, 1440px)
5. Screenshot the result of each interaction

Phase 3: Bug Report

For each bug found:

BUG-NNN: {title}
=================
Severity: CRITICAL / HIGH / MEDIUM / LOW
Flow: {which user flow}
Steps to reproduce:
  1. Navigate to {url}
  2. Click {element}
  3. Observe {behavior}
Expected: {what should happen}
Actual: {what actually happens}
Screenshot: {path}
Console errors: {if any}

Phase 4: Fix Loop

For each fixable bug, in severity order:

1. Locate source — find the file responsible
2. Fix — make the minimal change that resolves the bug
3. Write regression test — test encodes the exact bug condition: · Study existing test patterns in the repo first · Match the existing test framework (Vitest, Jest, Playwright, etc.) · Test the specific scenario that triggered the bug · Test should fail without the fix and pass with it
4. Run tests — verify all tests pass (existing + new)
5. Commit fix: fix(qa): BUG-NNN — description
6. Commit test: test(qa): regression test for BUG-NNN
7. Re-test in browser — navigate back and verify the fix

Phase 5: Responsive Testing

For each key page, test at three viewports:

agent-browser snapshot <url> --viewport 375x812    # mobile
agent-browser snapshot <url> --viewport 768x1024   # tablet
agent-browser snapshot <url> --viewport 1440x900   # desktop

Check:

• Layout breaks at each viewport?
• Touch targets >=44px on mobile?
• Horizontal scroll on any viewport?
• Navigation collapses appropriately?
• Text readable without zooming?

Phase 6: Compile Report

QA REPORT: {app name}
=====================
URL: {url}
Flows tested: N
Bugs found: N (Critical: X, High: Y, Medium: Z, Low: W)
Bugs fixed: N
Regression tests written: N

BUG-001: [CRITICAL] {title} — FIXED (commit: abc1234)
BUG-002: [HIGH] {title} — FIXED (commit: def5678)
BUG-003: [MEDIUM] {title} — DEFERRED (reason)

Responsive: {PASS / ISSUES at mobile / ISSUES at tablet}

Verdict: SHIP / FIX FIRST / NEEDS DISCUSSION

Self-Regulation

Every 5 fixes, evaluate:

• Am I still fixing real bugs or nitpicking?
• Have any fixes introduced new issues?
• Is the risk level acceptable?

Hard cap: 15 bug fixes. After 15, stop and report.

Anti-Patterns

• Testing without taking screenshots (no evidence)
• Fixing bugs without regression tests
• Bundling multiple bug fixes into one commit
• Testing only the happy path
• Skipping responsive testing
• Fixing design issues in a QA pass (that's gstack-design-review's job)
• Testing with developer tools open (users don't have dev tools)