Que fait Browser QA — Vérification visuelle et interaction automatisée ?
Quand l'utiliser
- Après avoir déployé une fonctionnalité sur l'environnement de staging/prévisualisation
- Lorsque vous devez vérifier le comportement de l'UI sur plusieurs pages
- Avant de livrer — confirmer que les dispositions, formulaires et interactions fonctionnent réellement
- Lors de la revue de PR qui touchent au code frontend
- Audits d'accessibilité et tests adaptatifs
Comment ça fonctionne
Utilise le MCP d'automatisation de navigateur (Claude-in-Chrome, Playwright ou Puppeteer) pour interagir avec des pages en ligne comme un véritable utilisateur.
La sécurité avant tout — rayon d'impact (exécution en lecture seule par défaut)
Browser QA pilote de véritables authentifications et parcours utilisateur, il faut donc traiter explicitement le rayon d'impact. Par défaut, en lecture seule : n'exécutez jamais un parcours mutant (achat, paiement, suppression, mise à jour massive) sur une URL de production — exigez un opt-in explicite et une URL de staging/prévisualisation. Utilisez des identifiants de test préparés, jamais de véritables logins de production, et masquez les identifiants/tokens/PII avant de sauvegarder une capture d'écran.
Phase 1 : Test préliminaire
1. Naviguer vers l'URL cible
2. Vérifier la présence d'erreurs dans la console (filtrer le bruit : analytics, tiers)
3. Vérifier l'absence d'erreur 4xx/5xx dans les requêtes réseau
4. Capturer la partie visible de la page sur le viewport desktop + mobile
5. Vérifier les Core Web Vitals : LCP < 2,5 s, CLS < 0,1, INP < 200 ms
(INP a remplacé FID en mars 2024 ; seuils selon web.dev)
Phase 2 : Test d'interaction
1. Cliquer sur chaque lien de navigation — vérifier l'absence de liens morts
2. Soumettre des formulaires avec des données valides — vérifier l'état de succès
3. Soumettre des formulaires avec des données invalides — vérifier l'état d'erreur
4. Tester le flux d'authentification : connexion → page protégée → déconnexion (identifiants de test uniquement, jamais la production)
5. Tester les parcours utilisateur critiques (achat, onboarding, recherche)
— en lecture seule par défaut ; n'exécuter des parcours mutants que sur staging
avec opt-in explicite (voir « La sécurité avant tout » ci-dessus)
Phase 3 : Régression visuelle
1. Capturer les pages clés à 3 points d'arrêt (375 px, 768 px, 1440 px)
2. Comparer avec les captures de référence validées
— pas de référence ⇒ signaler INCONCLUSIF, jamais un SUCCÈS silencieux
3. Signaler les décalages de mise en page > 5 px, les éléments manquants, les débordements
4. Vérifier le mode sombre si applicable
Phase 4 : Accessibilité
1. Exécuter axe-core ou un équivalent sur chaque page
2. Signaler les violations WCAG 2.2 AA (contraste, étiquettes, ordre de focus)
3. Vérifier que la navigation au clavier fonctionne de bout en bout
4. Vérifier les points de repère pour lecteurs d'écran
Remarque : axe-core couvre automatiquement environ 30 à 40 % des WCAG. Un passage propre est nécessaire, mais non suffisant — la navigation au clavier, l'ordre de focus et un passage avec lecteur d'écran nécessitent toujours une vérification manuelle. Ne rapportez pas « accessible » à partir d'un seul passage automatisé.
Format de sortie
## Rapport QA — [URL] — [horodatage]
### Test préliminaire
- Erreurs console : 0 critique, 2 avertissements (bruit analytics)
- Réseau : tout 200/304, aucune erreur
- Core Web Vitals : LCP 1,2 s ✓, CLS 0,02 ✓, INP 89 ms ✓
### Interactions
- [✓] Liens de navigation : 12/12 fonctionnent
- [✗] Formulaire de contact : état d'erreur manquant pour e-mail invalide
- [✓] Flux d'authentification : connexion/déconnexion fonctionne
### Visuel
- [✗] Section hero déborde sur le viewport 375 px
- [✓] Mode sombre : toutes les pages cohérentes
### Accessibilité
- 2 violations AA : texte alternatif manquant sur l'image hero, contraste insuffisant sur les liens du pied de page
### Verdict : LIVRER AVEC CORRECTIONS (2 problèmes, 0 bloquants)
# verdict ∈ LIVRER / LIVRER AVEC CORRECTIONS / NE PAS LIVRER ; utiliser INCONCLUSIF si aucune référence visuelle
Intégration
Fonctionne avec l'outil de navigateur disponible dans la session : Claude dans Chrome (mcp__claude-in-chrome__*), un serveur MCP Playwright, ou un simple script Playwright exécuté depuis le shell. Si aucun n'est disponible, indiquez-le et proposez un script Playwright plutôt que de deviner les résultats.
Pour des vérifications reproductibles, transformez les constatations en tests avec e2e-testing ; pour approfondir l'accessibilité, voir accessibility.