gabrielmoreira QA: Web Application Testing
Systematically test a web application for bugs, then fix and verify each issue found.
Three tiers of thoroughness. Diff-aware scoping tests what actually changed.
Instructions
Step 1: Scope Detection
Determine which pages and features to test.
Diff-aware mode (default): Identify affected routes from the current branch changes.
# Files changed in this branch
git diff --name-only origin/main...HEAD 2>/dev/null || git diff --name-only HEAD~5
# Identify affected routes from changed files
# e.g., changes in src/pages/dashboard/ → test /dashboard
# changes in api/payments/ → test payment flows
Full mode (/qa --full): Test the entire application, starting with critical paths.
Explicit scope (/qa /dashboard /settings): Test specified pages only.
Step 2: Tier Selection
| Tier | Flag | Scope | Use when |
|---|---|---|---|
| Quick | --quick |
Critical + High severity only | Pre-commit fast check |
| Standard | (default) | + Medium severity | Pre-PR review |
| Exhaustive | --exhaustive |
+ Low + cosmetic | Release candidate |
Step 3: Clean Working Tree
Before testing, ensure you can commit fixes atomically.
git status --short
If there are uncommitted changes: stash them first (git stash), or commit them. Testing on a dirty tree makes it impossible to isolate fix commits.
Step 4: Testing
For each page in scope, systematically check all categories relevant to the selected tier.
How to test
Use whatever browser tooling is available:
- MCP browser tools (if configured): automated navigation and screenshots
- Playwright/Puppeteer (if in the project): scripted test runs
- Manual testing: navigate to the URL, document findings systematically
For each page, cover:
1. Load the page: does it render without errors?
2. Check console: any uncaught errors, failed requests, warnings?
3. Test primary user action: the core thing this page is for
4. Test empty state: what shows when there's no data?
5. Test error state: what happens when an action fails?
6. Test on narrow viewport: does it break below 375px?
Issue taxonomy
Visual (layout, spacing, typography, colors, responsiveness) Functional (broken interactions, missing features, wrong behavior) UX (confusing flows, missing feedback, poor error messages) Content (typos, wrong copy, placeholder text in production) Performance (slow page loads, layout shifts, unoptimized images) Console (JavaScript errors, failed network requests, deprecation warnings) Accessibility (missing alt text, keyboard traps, missing labels, contrast)
Severity levels
| Severity | Criteria | Examples |
|---|---|---|
| Critical | Feature completely broken or data loss risk | 500 error, blank page, form that loses data |
| High | Major feature degraded, significant UX harm | Wrong data shown, broken primary CTA, mobile layout broken |
| Medium | Minor feature issue, noticeable but workaround exists | Visual glitch, confusing empty state, slow load |
| Low | Cosmetic, barely noticeable | Minor spacing, minor copy issue, low-severity console warning |
Quick tier: Critical + High only Standard tier: Critical + High + Medium Exhaustive tier: All severities
Step 5: Document Findings
Track each issue with a unique ID.
ISSUE-001
Severity: [Critical / High / Medium / Low]
Category: [Visual / Functional / UX / Content / Performance / Console / Accessibility]
Page: [URL or route]
Finding: [What is wrong, specific not vague]
Steps: [How to reproduce]
Expected: [What should happen]
Evidence: [Screenshot path or console output]
Step 6: Fix and Verify Loop
For each Critical and High issue (and Medium/Low in Standard/Exhaustive tiers):
- Fix the issue in source code
- Commit atomically: one commit per fix
git add <changed-files>
git commit -m "fix: <brief description of what was fixed>"
- Re-verify: navigate to the same page and confirm the issue is resolved
- Update the issue status to FIXED with the commit hash
Do not batch multiple fixes in one commit. Each fix must be individually revertable.
Output Format
QA REPORT
════════════════════════════════════════
Branch: [current branch]
Scope: [pages tested]
Tier: [Quick / Standard / Exhaustive]
Duration: [time taken]
HEALTH SCORES
─────────────────────────────────────────
Visual [PASS / WARN / FAIL] [N issues]
Functional [PASS / WARN / FAIL] [N issues]
UX [PASS / WARN / FAIL] [N issues]
Content [PASS / WARN / FAIL] [N issues]
Performance [PASS / WARN / FAIL] [N issues]
Console [PASS / WARN / FAIL] [N issues]
Accessibility [PASS / WARN / FAIL] [N issues]
ISSUES FOUND: N (X critical, Y high, Z medium, W low)
ISSUES FIXED: N
ISSUES REMAINING: N
─────────────────────────────────────────
ISSUE-001 [FIXED | OPEN]
Severity: High
Category: Functional
Page: /dashboard
Finding: Save button does nothing when form has validation errors, no feedback shown
Fix: Added error toast notification (commit abc1234)
ISSUE-002 [OPEN]
Severity: Medium
Category: Visual
Page: /settings
Finding: Input fields overflow container below 375px viewport
...
─────────────────────────────────────────
SHIP READINESS
Critical issues: [0 remaining / N remaining (BLOCKER)]
High issues: [0 remaining / N remaining (CONCERN)]
VERDICT: [READY TO SHIP / NOT READY: address critical and high issues first]
════════════════════════════════════════
Usage
/qa # Standard tier, diff-aware scope
/qa --quick # Quick tier (critical + high only)
/qa --exhaustive # Full coverage including cosmetic issues
/qa --full # Standard tier, test entire app (not just diff)
/qa /dashboard /settings # Test specific pages
/qa https://staging.app.com # Test a specific URL
Tips
- Run after every significant feature, not just before shipping
- Diff-aware first: test what changed before expanding scope
- Fix critical and high before continuing: don't pile up unfixed issues
- Screenshot evidence: always capture before/after for critical fixes
- Check mobile: most visual bugs appear at 375px width
Related Commands
/investigate: root-cause analysis when QA finds a complex bug/ship: pre-deploy checklist (run after QA passes)/canary: post-deploy monitoring (run after shipping)
$ARGUMENTS