Browser-QA — Automatisierte visuelle Tests & Interaktionen
Wann verwenden
- Nach dem Deployment einer Funktion auf Staging/Preview
- Wenn Sie das UI-Verhalten über mehrere Seiten prüfen müssen
- Vor dem Ausliefern – bestätigen, dass Layouts, Formulare und Interaktionen tatsächlich funktionieren
- Bei der Überprüfung von PRs, die Frontend-Code betreffen
- Barrierefreiheits-Audits und responsive Tests
Funktionsweise
Nutzt das Browser-Automatisierungs-MCP (Claude-in-Chrome, Playwright oder Puppeteer), um wie ein echter Benutzer mit Live-Seiten zu interagieren.
Sicherheit zuerst – Schadensradius (standardmäßig schreibgeschützt ausführen)
Browser-QA steuert echte Authentifizierung und echte Benutzer-Journeys, daher muss der Schadensradius explizit betrachtet werden. Standardmäßig schreibgeschützt: Führen Sie niemals eine mutierende Journey (Checkout, Zahlung, Löschen, Massenaktualisierung) gegen eine Produktions-URL aus – erfordert eine explizite Zustimmung und eine Staging-/Vorschau-URL. Verwenden Sie bereitgestellte Test-Anmeldedaten, niemals echte Produktions-Logins, und schwärzen Sie Anmeldedaten/Tokens/PII, bevor Sie Screenshots speichern.
Phase 1: Smoke-Test
1. Navigieren Sie zur Ziel-URL
2. Prüfen Sie auf Konsolenfehler (Rauschen filtern: Analytics, Drittanbieter)
3. Stellen Sie sicher, dass keine 4xx/5xx in Netzwerkanfragen auftreten
4. Machen Sie einen Screenshot des sichtbaren Bereichs auf Desktop + Mobile
5. Prüfen Sie 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. Klicken Sie jeden Nav-Link – prüfen Sie auf keine toten Links
2. Senden Sie Formulare mit gültigen Daten – prüfen Sie auf Erfolgsstatus
3. Senden Sie Formulare mit ungültigen Daten – prüfen Sie auf Fehlerstatus
4. Testen Sie den Auth-Ablauf: Login → geschützte Seite → Logout (nur Test-Anmeldedaten, niemals Produktion)
5. Testen Sie kritische Benutzer-Journeys (Checkout, Onboarding, Suche)
– standardmäßig schreibgeschützt; mutierende Journeys nur gegen Staging
mit expliziter Zustimmung (siehe „Sicherheit zuerst" oben)
Phase 3: Visuelle Regression
1. Machen Sie Screenshots wichtiger Seiten bei 3 Breakpoints (375px, 768px, 1440px)
2. Vergleichen Sie mit den bereitgestellten Basis-Screenshots
– keine Basis ⇒ UNENTSCHEIDBAR melden, niemals stillschweigend BESTANDEN
3. Markieren Sie Layout-Verschiebungen > 5px, fehlende Elemente, Überläufe
4. Prüfen Sie den Dark Mode, falls zutreffend
Phase 4: Barrierefreiheit
1. Führen Sie axe-core oder ein Äquivalent auf jeder Seite aus
2. Markieren Sie WCAG 2.2-AA-Verstöße (Kontrast, Labels, Fokus-Reihenfolge)
3. Prüfen Sie, ob die Tastaturnavigation durchgängig funktioniert
4. Prüfen Sie die Screenreader-Orientierungspunkte
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 weiterhin manuell geprüft werden. Melden Sie nicht „barrierefrei" allein aufgrund eines automatisierten Durchlaufs.
Ausgabeformat
## QA-Bericht — [URL] — [Zeitstempel]
### Smoke-Test
- Konsolenfehler: 0 kritische, 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 funktionsfähig
- [✗] Kontaktformular: Fehlerstatus für ungültige E-Mail fehlt
- [✓] Auth-Ablauf: Login/Logout funktioniert
### Visuelles
- [✗] Hero-Bereich läuft bei 375px über
- [✓] Dark Mode: alle Seiten konsistent
### Barrierefreiheit
- 2 AA-Verstöße: fehlender Alternativtext auf Hero-Bild, geringer Kontrast bei Footer-Links
### Urteil: SHIP WITH FIXES (2 Probleme, 0 Blocker)
# urteil ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP; verwenden Sie UNENTSCHEIDBAR, wenn keine visuelle Basis vorhanden ist
Integration
Funktioniert mit jedem Browser-Tool, das die Sitzung hat: Claude in Chrome (mcp__claude-in-chrome__*), einen Playwright-MCP-Server oder ein einfaches Playwright-Skript, das von der Shell aus ausgeführt wird. Wenn keines verfügbar ist, sagen Sie dies und bieten Sie stattdessen ein Playwright-Skript an, anstatt Ergebnisse zu erraten.
Für wiederholbare Prüfungen wandeln Sie die Erkenntnisse mit e2e-testing in Tests um; für vertiefte Barrierefreiheit siehe accessibility.