Browser QA — Automatisierte visuelle Tests & Interaktionen
Wann verwenden
- Nach der Bereitstellung eines Features auf Staging/Preview
- Wenn UI-Verhalten über Seiten hinweg überprüft werden muss
- Vor dem Ausliefern — Layouts, Formulare, Interaktionen auf Korrektheit prüfen
- Bei der Überprüfung von Pull Requests mit Frontend-Änderungen
- Barrierefreiheitsaudits und responsive Tests
Funktionsweise
Verwendet das Browser-Automatisierungs-MCP (claude-in-chrome, Playwright oder Puppeteer), um wie ein echter Benutzer mit Live-Seiten zu interagieren.
Sicherheit zuerst — Wirkungsbereich (Standardmäßig schreibgeschützt)
Browser QA steuert echte Authentifizierung und echte Benutzerabläufe. Behandeln Sie den Wirkungsbereich daher explizit. Standardmäßig schreibgeschützt: Führen Sie niemals einen mutierenden Ablauf (Checkout, Zahlung, Löschen, Massenaktualisierung) gegen eine Produktions-URL aus — verlangen Sie explizites Opt-in und eine Staging/Preview-URL. Verwenden Sie bereitgestellte Test-Anmeldeinformationen, niemals echte Produktions-Logins, und schwärzen Sie Anmeldeinformationen/Token/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 Netzwerkanfragen auftreten
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 gemäß web.dev)
Phase 2: Interaktionstest
1. Klicke jeden Navigationslink — überprüfe auf keine toten Links
2. Sende Formulare mit gültigen Daten — überprüfe Erfolgszustand
3. Sende Formulare mit ungültigen Daten — überprüfe Fehlerzustand
4. Teste den Authentifizierungsablauf: Login → geschützte Seite → Logout (nur Test-Anmeldeinformationen, niemals Produktion)
5. Teste kritische Benutzerabläufe (Checkout, Onboarding, Suche)
— standardmäßig schreibgeschützt; mutierende Abläufe nur gegen Staging
mit explizitem Opt-in ausführen (siehe „Sicherheit zuerst" oben)
Phase 3: Visuelle Regression
1. Screenshot von Schlüsselseiten bei 3 Breakpoints (375px, 768px, 1440px)
2. Vergleiche mit gespeicherten Basis-Screenshots
— kein Basis-Screenshot ⇒ INCONCLUSIVE melden, niemals stillen PASS
3. Markiere Layout-Verschiebungen >5px, fehlende Elemente, Überlauf
4. Überprüfe den 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, Labels, Fokus-Reihenfolge)
3. Überprüfe, ob die Tastaturnavigation durchgängig funktioniert
4. Überprüfe Screenreader-Landmarken
Hinweis: axe-core deckt automatisch etwa 30–40% der WCAG ab. Ein sauberer Durchlauf ist notwendig, nicht ausreichend — Tastaturnavigation, Fokus-Reihenfolge und ein Screenreader-Durchlauf müssen dennoch manuell geprüft werden. Melden Sie „barrierefrei" nicht allein aufgrund eines automatisierten Durchlaufs.
Ausgabeformat
## QA-Report — [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
- [✓] Navigationslinks: 12/12 funktionieren
- [✗] Kontaktformular: Fehlerzustand für ungültige E-Mail fehlt
- [✓] Authentifizierungsablauf: Login/Logout funktioniert
### Visuell
- [✗] Hero-Bereich läuft bei 375px-Viewport über
- [✓] Dark Mode: alle Seiten konsistent
### Barrierefreiheit
- 2 AA-Verstöße: fehlender Alternativtext im Hero-Bild, geringer Kontrast bei Footer-Links
### Entscheidung: SHIP WITH FIXES (2 Probleme, 0 Blocker)
# Entscheidung ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP; INCONCLUSIVE verwenden, wenn keine visuelle Baseline vorhanden
Integration
Funktioniert mit jedem Browser-MCP:
mChild__claude-in-chrome__*-Tools (bevorzugt — verwendet Ihren tatsächlichen Chrome)- Playwright via
mcp__browserbase__* - Direkte Puppeteer-Skripte
Kombinieren mit /canary-watch für die Überwachung nach der Bereitstellung.