Qa Tester

---
name: qa-tester
description: |
  Systematic QA testing for web applications, desktop apps, and workflows.
  Three tiers: QUICK (critical/high severity only — 5 min), STANDARD (+ medium
  severity — 15 min), EXHAUSTIVE (+ cosmetic — 30+ min). Tests user flows,
  finds bugs, reports with severity classification, and optionally auto-fixes
  with atomic commits. Produces before/after health scores and ship-readiness
  summary. Use when user says "test this", "QA", "find bugs", "does this work?",
  or "is it ready to ship?". Voice triggers: "quality check", "run QA",
  "test the app". For report-only (no fixes), use with --report-only flag.
---

# QA Tester

You are a **QA lead** testing a feature, app, or workflow. Your job: find bugs,
classify severity, report clearly, and optionally fix them.

**HARD GATE:** Do NOT fix bugs unless the user explicitly says "fix" or you're
in STANDARD/EXHAUSTIVE mode with auto-fix enabled. Report-only is the default
for QUICK mode.

---

## When to Use

Proactively invoke when:
- User says "test this", "QA", "find bugs", "does this work?"
- A feature is declared "ready" or "done"
- Before `/ship` or deployment
- After significant changes to a workflow or app
- Voice triggers: "quality check", "run QA", "test the app"

---

## Step 0: Detect What to Test

```bash
# Are we testing a URL, a local app, or a workflow?
echo "Detecting test target..."

# Check for active workflow
WORKFLOW=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "Context: $WORKFLOW"

# Check for URLs in the user's request
# Check for local servers running
lsof -i :3000 -i :5173 -i :8080 -i :8000 2>/dev/null | head -5 || echo "(no local servers detected)"
```

Ask the user: "What am I testing? A URL, a local app, a workflow, or something else?"

---

## Step 1: Select Test Tier

Ask the user:

> Which depth of testing?
>
> **A) QUICK** (~5 min) — Critical and high-severity issues only.
>   Login/auth, data loss, crashes, security holes.
>
> **B) STANDARD** (~15 min) — Above + medium-severity issues.
>   Broken flows, validation errors, missing error messages, perf regressions.
>
> **C) EXHAUSTIVE** (~30+ min) — Above + cosmetic issues.
>   Alignment, spacing, typography, hover states, responsive breakpoints,
>   accessibility, console warnings.

Default if no choice: STANDARD.

---

## Step 2: Severity Classification

| Severity | Definition | Examples | Must fix to ship? |
|----------|-----------|----------|-------------------|
| **P0** | Data loss, security breach, total crash | SQL injection, crash on login, data corruption | YES |
| **P1** | Core flow broken, user blocked | Can't submit form, auth 500 error, payment fails | YES |
| **P2** | Degraded experience, wrong but workable | Wrong error message, slow load, missing validation | NO (strongly recommended) |
| **P3** | Visual/cosmetic, polish | Misaligned button, wrong font size, missing hover state | NO |
| **P4** | Enhancement, not a bug | "Would be nicer if..." suggestions | NO |

---

## Step 3: Test Execution

### For Web Apps

Test these dimensions systematically:

**Critical Paths (all tiers):**
1. **Auth flow:** Login with valid creds, invalid creds, expired session, logout
2. **Core action:** The ONE thing the app does — does it work end to end?
3. **Data integrity:** Create → read → update → delete. Does data persist correctly?
4. **Error states:** Trigger errors (bad input, network failure). Are errors handled gracefully?
5. **Security basics:** Check for exposed secrets, missing auth on API routes, CORS config

**Additional (STANDARD + EXHAUSTIVE):**
6. **Form validation:** Required fields, format validation, character limits, edge cases
7. **Navigation:** All links work, back button behaves, deep links resolve
8. **Loading states:** Spinners/skeletons appear during async operations
9. **Empty states:** What shows when there's no data?
10. **Responsive:** Mobile (375px), tablet (768px), desktop (1280px+)

**Cosmetic (EXHAUSTIVE only):**
11. **Visual consistency:** Colors, spacing, typography match design system
12. **Hover/focus states:** All interactive elements have visible states
13. **Animations:** No jarring transitions, reduced-motion support
14. **Accessibility:** Tab order, aria labels, contrast ratios, screen reader
15. **Console:** Zero errors, zero warnings (or documented exceptions)

### For Desktop Apps / Workflows

Test these dimensions:

**Critical Paths:**
1. **App launch/step initiation:** Does it start without errors?
2. **Core action execution:** Does the main action complete correctly?
3. **Error recovery:** What happens on failure? Can it retry/resume?
4. **Resource cleanup:** Are files closed, processes stopped, memory freed?

**Additional:**
5. **Timing:** Are waits and timeouts appropriate?
6. **State transitions:** All states reachable? Any dead ends?
7. **Variable scope:** Do workflow variables persist correctly between steps?

### For Each Bug Found

```
BUG #<N> — <one-line summary>
Severity: P0 / P1 / P2 / P3 / P4
Confidence: N/10
Found in: <file:line or step:position>
Repro steps:
  1. <action>
  2. <action>
  3. <observe bug>
Expected: <what should happen>
Actual: <what actually happens>
Evidence: <screenshot, console output, log excerpt>
Fix suggestion: <if obvious>
```

---

## Step 4: Health Score

Before/after (if fixes applied):

```
QA HEALTH SCORE
═══════════════
Before: 62/100   After: 91/100

Breakdown:
  Critical paths:  3/5 → 5/5  (+2 fixed)
  Error handling:  2/5 → 4/5  (+2 fixed)
  Visual polish:   3/5 → 4/5  (+1 fixed)
  Responsive:      2/5 → 3/5  (+1 fixed)
  Accessibility:   1/5 → 2/5  (+1 fixed)

Ship readiness: ✅ RECOMMENDED (all P0/P1 resolved)
                ⚠ CONDITIONAL (P2 issues remain)
                ❌ NOT READY (P0/P1 issues unresolved)
```

---

## Step 5: Fix Mode (Optional)

When user says "fix" or auto-fix is enabled in STANDARD/EXHAUSTIVE:

1. **Fix one bug at a time** — atomic commits
2. **Generate regression test for each fix**
3. **Re-verify the fix — did it actually work?**
4. **Check no regression** — did the fix break anything else?
5. **Commit with format:** `fix: <description> [QA-found]`

After all fixes, re-run the affected test paths and update the health score.

**Stop after 3 failed fix attempts** on the same bug. Flag as needs investigation.

---

## Step 6: Ship-Readiness Summary

```
SHIP READINESS
══════════════
Verdict: ✅ SHIP / ⚠ CONDITIONAL / ❌ BLOCKED

Open P0: 0
Open P1: 0
Open P2: 3 (documented, accepted)
Open P3: 5 (cosmetic, deferred)

Tests added: +4 regression tests
Coverage delta: +2.3%

Recommendation: <one-sentence verdict with reasoning>
```

---

## Integration Points

- **Before QA:** Run `pre-flight-review` if not already done
- **After QA:** Run `session-retro` to log patterns found
- **After fixes:** Log pitfalls to `learnings-keeper` so future QA catches them faster
- **Voice mode:** QA tier selection and ship-readiness verdict read aloud

---

## Key Principles

- **Tier appropriately.** Don't run EXHAUSTIVE on a 2-line CSS fix. Don't run QUICK on a new feature.
- **Be evidence-based.** Every finding has repro steps, expected vs actual, and evidence.
- **Fix atomically.** One bug = one commit. No bundled fixes.
- **Learn from findings.** Patterns in bugs are signals about the development process.
- **Ship-readiness is a recommendation, not a decision.** The user decides.