Browser QA — Automatisierte visuelle Tests & Interaktionen
Wann verwenden
- Nach dem Deployment eines Features auf Staging/Preview
- Wenn das UI-Verhalten über mehrere Seiten hinweg überprüft werden soll
- Vor dem Ausliefern – sicherstellen, dass Layouts, Formulare und Interaktionen tatsächlich funktionieren
- Beim Reviewen von PRs, die Frontend-Code betreffen
- Accessibility-Audits und Responsive-Tests
So funktioniert es
Nutzt das Browser-Automatisierungs-MCP (claude-in-chrome, Playwright oder Puppeteer), um mit Live-Seiten wie ein echter Benutzer zu interagieren.
Sicherheit zuerst — Blast Radius (standardmäßig schreibgeschützt)
Browser QA steuert echte Authentifizierung und echte Benutzerreisen, daher behandle den Blast Radius explizit. Standardmäßig schreibgeschützt: Führe niemals eine mutierende Reise (Checkout, Zahlung, Löschen, Massen-Update) gegen eine Produktions-URL aus – erfordere ein explizites Opt-in und eine Staging/Preview-URL. Verwende bereitgestellte Test-Anmeldedaten, niemals echte Produktions-Logins, und schwärze Anmeldedaten/Tokens/PII vor dem Speichern von Screenshots.
Phase 1: Smoke-Test
1. Navigiere zur Ziel-URL
2. Überprüfe auf Konsolenfehler (Rauschen filtern: Analytics, Drittanbieter)
3. Stelle sicher, dass keine 4xx/5xx in Netzwerk-Anfragen vorkommen
4. Screenshot des sichtbaren Bereichs auf Desktop + Mobile-Viewport
5. Überprüfe Core Web Vitals: LCP < 2,5s, CLS < 0,1, INP < 200ms
(INP ersetzte FID im März 2024; Schwellenwerte laut web.dev)
Phase 2: Interaktionstest
1. Klicke jeden Nav-Link – stelle sicher, dass keine toten Links vorhanden sind
2. Sende Formulare mit gültigen Daten – überprüfe den Erfolgsstatus
3. Sende Formulare mit ungültigen Daten – überprüfe den Fehlerstatus
4. Teste den 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 mutierende Reisen nur gegen Staging
mit explizitem Opt-in durch (siehe „Sicherheit zuerst“ oben)
Phase 3: Visuelles Regressionstesting
1. Screenshot von Schlüsselseiten bei 3 Breakpoints (375px, 768px, 1440px)
2. Vergleiche mit festgelegten Baseline-Screenshots
– keine Baseline ⇒ melde INCONCLUSIVE, niemals ein stilles PASS
3. Melde Layout-Verschiebungen > 5px, fehlende Elemente, Überlauf
4. Überprüfe den Dunkelmodus, falls zutreffend
Phase 4: Barrierefreiheit (Accessibility)
1. Führe axe-core oder Äquivalent auf jeder Seite aus
2. Melde WCAG 2.2 AA-Verstöße (Kontrast, Labels, Fokusreihenfolge)
3. Überprüfe, ob die Tastaturnavigation durchgängig funktioniert
4. Überprüfe Screenreader-Landmarks
Hinweis: axe-core deckt automatisch etwa 30–40 % der WCAG ab. Ein sauberer Durchlauf ist notwendig, nicht ausreichend – Tastaturnavigation, Fokusreihenfolge und ein Screenreader-Durchlauf benötigen weiterhin eine manuelle Überprüfung. Melde nicht „barrierefrei“ allein aufgrund eines automatisierten Durchlaufs.
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: Fehlerstatus für ungültige E-Mail fehlt
- [✓] Auth-Flow: Login/Logout funktioniert
### Visuell
- [✗] Hero-Bereich läuft bei 375px-Viewport über
- [✓] Dunkelmodus: alle Seiten konsistent
### Barrierefreiheit
- 2 AA-Verstöße: fehlender Alternativtext im Hero-Bild, geringer Kontrast in Footer-Links
### Urteil: SHIP WITH FIXES (2 Probleme, 0 Blocker)
# Urteil ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP; verwende INCONCLUSIVE, wenn keine visuelle Baseline vorhanden ist
Integration
Funktioniert mit jedem Browser-MCP:
mChild__claude-in-chrome__*Tools (bevorzugt – verwendet deinen tatsächlichen Chrome)- Playwright über
mcp__browserbase__* - Direkte Puppeteer-Skripte
Kombiniere mit /canary-watch für das Post-Deployment-Monitoring.