---
name: qa-systematic
description: 'Systematic web application QA testing with issue taxonomy, health scoring, and regression tracking. Triggers on: "QA this", "test the app", "smoke test", "run QA", "systematic test", "regression test", "full QA", "/qa-systematic".'
metadata:
  version: 1.0.1
  category: development
  tags: [qa, testing, browser, regression]
  difficulty: advanced
  phase: verify
---

# Systematic QA Testing

## Modes

### Full (default)

Systematic page-by-page testing, 8-category health score, full issue documentation.

### Quick

30-second smoke test of critical paths only: login, main nav, primary action.

### Regression

Diff current state against saved baseline, report new/resolved issues.

## Browser Automation Detection

Detect available automation in priority order:

1. **Playwright MCP server** — check if Playwright tools are available in the current tool list
2. **`agent-browser` skill** — check if the agent-browser skill is loaded
3. **Direct CLI tools** — check for `playwright`, `puppeteer`, or `cypress` binaries on PATH
4. **Manual fallback** — instruct the user to navigate and report observations

Use the highest-priority method available. State which method is in use at the start of the report.

## Workflow

### Phase 1: Initialize

1. Detect mode from user prompt. Default to **full** if unspecified.
2. Detect application URL:
   - Check `references/project-detection.md` for framework port conventions (e.g., Next.js → 3000, Vite → 5173, Django → 8000).
   - If not detectable, ask the user.
3. Detect available browser automation method (priority list above).
4. If regression mode: load previous baseline from `.qa-reports/`.

### Phase 2: Authenticate (if needed)

1. Navigate to root URL and check if a login wall is present.
2. If credentials were provided: authenticate and store session.
3. If not: ask the user for test credentials, or skip auth-gated pages and note the gap in the report.

### Phase 3: Orient

1. Navigate to root URL.
2. Map the primary navigation structure — collect all top-level nav links.
3. Classify each page: static, form, list, detail, dashboard.
4. Build a test plan ordered by page category (forms and dashboards first — highest defect density).

### Phase 4: Explore (Full mode)

For each page, run the per-page checklist below. In quick mode, run only the items marked with (Q).

#### Visual Scan

- (Q) Layout renders correctly — no overlap, no overflow
- Images load — no broken `<img>` tags
- Typography consistent — no visible font fallbacks
- Responsive: check at desktop (1280px) and mobile (375px) widths

#### Interactive Elements

- (Q) All buttons and links are clickable and responsive
- Hover states present where expected
- Focus indicators visible for keyboard navigation
- Disabled states visually distinct

#### Forms

- (Q) Required field validation fires on empty submit
- Error messages display on invalid input
- Success feedback on valid submission
- Form resubmission handled — no duplicate submissions on double-click

#### Navigation

- (Q) All nav links resolve — no 404s
- Back button works as expected
- Deep links work — direct URL access returns correct page
- Breadcrumbs accurate (if present)

#### State Management

- Loading states displayed during async operations
- Empty states handled — no blank pages when data is absent
- Error states recoverable — retry or back options present
- Data persists across navigation — no lost form data on back/forward

#### Console

- (Q) No JavaScript errors in console
- No failed network requests (4xx/5xx)
- No mixed content warnings
- No deprecation warnings in hot paths

#### Responsiveness

- Mobile layout usable — no horizontal scroll at 375px
- Touch targets >= 44px
- Text readable without zoom (>= 16px body text)

### Phase 5: Document

For each issue found, classify using `references/issue-taxonomy.md`:

- **Severity**: critical (blocks usage), major (degrades experience), minor (cosmetic/polish)
- **Category**: functional, visual, accessibility, performance, content, navigation, security, console
- **Evidence**: screenshot description or reproduction steps

Assign a unique ID: `QA-001`, `QA-002`, etc.

Compute health score using the weights defined below and detailed in `references/report-template.md`.

### Phase 6: Wrap Up

1. Generate structured report following `references/report-template.md`.
2. Save to `.qa-reports/<YYYY-MM-DD>-<mode>.json`.
3. If full mode: save baseline for future regression comparison.
4. Present summary: health score, critical/major/minor counts, top 3 priority fixes.

## Health Score

Weighted average across 8 categories, scored 0-100.

| Category       | Weight |
| -------------- | ------ |
| Console errors | 15%    |
| Broken links   | 10%    |
| Functional     | 20%    |
| UX/Usability   | 15%    |
| Accessibility  | 15%    |
| Visual         | 10%    |
| Performance    | 10%    |
| Content        | 5%     |

**Scoring per category**: start at 100, deduct per issue by severity:

- Critical: -30
- Major: -15
- Minor: -5

Floor at 0. Final health score = weighted sum of category scores.

## Quick Mode Behavior

Run only items marked (Q) in the Phase 4 checklist. Skip health score computation — report pass/fail per critical path. Target completion: 30 seconds of actual testing time.

## Regression Mode Behavior

1. Load the most recent baseline from `.qa-reports/`.
2. Run full mode.
3. Diff issues by ID and description similarity.
4. Report: new issues, resolved issues, persistent issues.
5. Save updated baseline.