qa-systematic

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.