browser-qa

Browser QA — Automatisierte visuelle Tests & Interaktion

Wann verwenden

• Nachdem eine Funktion in Staging/Preview bereitgestellt wurde
• Wenn du das UI-Verhalten über mehrere Seiten hinweg überprüfen musst
• Vor dem Ausliefern — um sicherzustellen, dass Layouts, Formulare und Interaktionen tatsächlich funktionieren
• Beim Reviewen von PRs, die Frontend-Code betreffen
• Barrierefreiheits-Audits und responsives Testen

Funktionsweise

Nutzt das Browser-Automatisierungs-MCP (claude-in-chrome, Playwright oder Puppeteer), um mit Live-Seiten wie ein echter Benutzer zu interagieren.

Sicherheit zuerst — Schadensradius (standardmäßig schreibgeschützt ausführen)

Browser QA steuert echte Authentifizierung und echte Benutzerreisen — behandle den Schadensradius daher explizit. Standardmäßig schreibgeschützt: Führe niemals eine ändernde Reise (Checkout, Zahlung, Löschen, Massenaktualisierung) gegen eine Produktions-URL aus — erfordere eine explizite Opt-in und eine Staging/Preview-URL. Verwende gesäte Test-Anmeldedaten, niemals echte Produktions-Logins, und schwärze Anmeldedaten/Tokens/PII, bevor du Screenshots speicherst.

Phase 1: Smoke-Test

1. Navigiere zur Ziel-URL
2. Prüfe auf Konsolenfehler (Rauschen filtern: Analytics, Drittanbieter)
3. Bestätige keine 4xx/5xx in Netzwerkanfragen
4. Screenshot des oberen Bildschirmbereichs auf Desktop + mobilem Viewport
5. Prüfe Core Web Vitals: LCP < 2,5s, CLS < 0,1, INP < 200ms
   (INP hat FID im März 2024 ersetzt; Schwellenwerte laut web.dev)

Phase 2: Interaktionstest

1. Klicke jeden Nav-Link — bestätige keine toten Links
2. Sende Formulare mit gültigen Daten — bestätige Erfolgszustand
3. Sende Formulare mit ungültigen Daten — bestätige Fehlerzustand
4. Teste Auth-Flow: Login → geschützte Seite → Logout (nur Test-Anmeldedaten, niemals Produktion)
5. Teste kritische Benutzerreisen (Checkout, Onboarding, Suche)
   — standardmäßig schreibgeschützt; führe ändernde Reisen nur gegen Staging
     mit expliziter Opt-in aus (siehe „Sicherheit zuerst" oben)

Phase 3: Visueller Regressionstest

1. Screenshot von Schlüsselseiten bei 3 Breakpoints (375px, 768px, 1440px)
2. Vergleiche mit festgelegten Basis-Screenshots
   — kein Basis ⇒ melde UNENTSCHEIDBAR, niemals stilles BESTANDEN
3. Markiere Layoutverschiebungen > 5px, fehlende Elemente, Überläufe
4. Prüfe Dark Mode, falls zutreffend

Phase 4: Barrierefreiheit

1. Führe axe-core oder Äquivalent auf jeder Seite aus
2. Markiere WCAG 2.2 AA-Verstöße (Kontraste, Beschriftungen, Fokus-Reihenfolge)
3. Bestätige, dass Tastaturnavigation Ende-zu-Ende funktioniert
4. Prüfe Screenreader-Landmarken

Hinweis: axe-core deckt automatisch etwa 30–40 % der WCAG ab. Eine saubere Ausführung ist notwendig, nicht hinreichend — Tastaturnavigation, Fokus-Reihenfolge und ein Screenreader-Durchlauf benötigen weiterhin eine manuelle Prüfung. Melde „barrierefrei" nicht allein aufgrund einer automatischen Prüfung.

Ausgabeformat

## QA-Bericht — [URL] — [Zeitstempel]

### Smoke-Test
- Konsolenfehler: 0 kritisch, 2 Warnungen (Analytics-Rauschen)
- Netzwerk: alle 200/304, keine Fehler
- Core Web Vitals: LCP 1,2s ✓, CLS 0,02 ✓, INP 89ms ✓

### Interaktionen
- [✓] Nav-Links: 12/12 funktionieren
- [✗] Kontaktformular: Fehlerzustand für ungültige E-Mail fehlt
- [✓] Auth-Flow: Login/Logout funktioniert

### Visuell
- [✗] Hero-Bereich läuft bei 375px Viewport über
- [✓] Dark Mode: alle Seiten konsistent

### Barrierefreiheit
- 2 AA-Verstöße: fehlender Alternativtext auf Hero-Bild, geringer Kontrast bei Footer-Links

### Urteil: AUSLIEFERN MIT KORREKTUREN (2 Probleme, 0 Blocker)
# Urteil ∈ AUSLIEFERN / AUSLIEFERN MIT KORREKTUREN / NICHT AUSLIEFERN; verwende UNENTSCHEIDBAR, wenn keine visuelle Basis vorhanden

Integration

Funktioniert mit jedem Browser-MCP:

• mChild__claude-in-chrome__*-Tools (bevorzugt — verwendet dein tatsächliches Chrome)
• Playwright via mcp__browserbase__*
• Direkte Puppeteer-Skripte

Kombinieren mit /canary-watch für Post-Deploy-Überwachung.