Dogfood (Explorateur QA)

Que fait Dogfood (Explorateur QA) ?

Explorez systématiquement une application web, trouvez des problèmes et produisez un rapport avec des preuves de reproduction complètes pour chaque constatation.

Configuration

Seule l'URL cible est requise. Tout le reste a des valeurs par défaut raisonnables — utilisez-les sauf si l'utilisateur fournit explicitement une surcharge.

Paramètre	Valeur par défaut	Exemple de surcharge
URL cible	(requis)	vercel.com, http://localhost:3000
Nom de session	Domaine slugifié (ex. vercel.com -> vercel-com)	--session ma-session
Répertoire de sortie	./dogfood-output/	Répertoire de sortie: /tmp/qa
Périmètre	Application complète	Concentrez-vous sur la page de facturation
Authentification	Aucune	Connectez-vous à [email protected]

Si l'utilisateur dit quelque chose comme "dogfood vercel.com", commencez immédiatement avec les valeurs par défaut. Ne posez pas de questions de clarification, sauf si l'authentification est mentionnée mais que les identifiants sont manquants.

Utilisez toujours agent-browser directement — jamais npx agent-browser. Le binaire direct utilise le client Rust rapide. npx passe par Node.js et est nettement plus lent.

Flux de travail

1. Initialiser     Configurer la session, les répertoires de sortie, le fichier rapport
2. Authentifier    Se connecter si nécessaire, enregistrer l'état
3. Orienter        Naviguer vers le point de départ, prendre un instantané initial
4. Explorer        Visiter systématiquement les pages et tester les fonctionnalités
5. Documenter      Capturer d'écran + enregistrer chaque problème au fur et à mesure
6. Finaliser       Mettre à jour les comptes récapitulatifs, fermer la session

1. Initialiser

mkdir -p {OUTPUT_DIR}/screenshots {OUTPUT_DIR}/videos

Copiez le modèle de rapport dans le répertoire de sortie et remplissez les champs d'en-tête :

cp {SKILL_DIR}/templates/dogfood-report-template.md {OUTPUT_DIR}/report.md

Démarrez une session nommée :

agent-browser --session {SESSION} open {TARGET_URL}
agent-browser --session {SESSION} wait --load domcontentloaded

2. Authentifier

Si l'application nécessite une connexion :

agent-browser --session {SESSION} snapshot -i
# Identifier les références du formulaire de connexion, remplir les identifiants
agent-browser --session {SESSION} fill @e1 "{EMAIL}"
agent-browser --session {SESSION} fill @e2 "{MOT_DE_PASSE}"
agent-browser --session {SESSION} click @e3
# Remplacer ceci par l'URL post-connexion, le texte ou la condition JS de l'application cible :
agent-browser --session {SESSION} wait --url "{URL_POST_CONNEXION}"
# Ou :
# agent-browser --session {SESSION} wait --text "{TEXTE_POST_CONNEXION}"
# agent-browser --session {SESSION} wait --fn "{CONDITION_POST_CONNEXION}"

Pour les codes OTP/e-mail : demandez à l'utilisateur, attendez sa réponse, puis saisissez le code.

Après une connexion réussie, enregistrez l'état pour une réutilisation potentielle :

agent-browser --session {SESSION} state save {OUTPUT_DIR}/auth-state.json

3. Orienter

Prenez une capture d'écran annotée initiale et un instantané pour comprendre la structure de l'application :

agent-browser --session {SESSION} screenshot --annotate {OUTPUT_DIR}/screenshots/initial.png
agent-browser --session {SESSION} snapshot -i

Identifiez les principaux éléments de navigation et cartographiez les sections à visiter.

4. Explorer

Consultez references/issue-taxonomy.md pour la liste complète des éléments à rechercher et la checklist d'exploration.

Stratégie — parcourez l'application systématiquement :

• Commencez par la navigation principale. Visitez chaque section de premier niveau.
• Dans chaque section, testez les éléments interactifs : cliquez sur les boutons, remplissez les formulaires, ouvrez les menus déroulants/modales.
• Vérifiez les cas limites : états vides, gestion des erreurs, saisies aux limites.
• Essayez des workflows réalistes de bout en bout (création, modification, suppression).
• Vérifiez périodiquement la console du navigateur pour les erreurs.

Sur chaque page :

agent-browser --session {SESSION} snapshot -i
agent-browser --session {SESSION} screenshot --annotate {OUTPUT_DIR}/screenshots/{nom-page}.png
agent-browser --session {SESSION} errors
agent-browser --session {SESSION} console

Utilisez votre jugement pour décider de la profondeur. Passez plus de temps sur les fonctionnalités principales et moins sur les pages périphériques. Si vous trouvez un groupe de problèmes dans une zone, approfondissez.

5. Documenter les problèmes (Repro en premier)

Les étapes 4 et 5 se déroulent ensemble — explorez et documentez en un seul passage. Lorsque vous trouvez un problème, arrêtez d'explorer et documentez-le immédiatement avant de continuer. N'explorez pas toute l'application d'abord pour documenter ensuite.

Chaque problème doit être reproductible. Lorsque vous trouvez quelque chose qui ne va pas, ne le notez pas seulement — prouvez-le avec des preuves. L'objectif est que quelqu'un lisant le rapport puisse voir exactement ce qui s'est passé et le rejouer.

Choisissez le niveau de preuve approprié pour le problème :

Problèmes interactifs / comportementaux (fonctionnels, UX, erreurs de console lors d'une action)

Ces problèmes nécessitent une interaction utilisateur pour être reproduits — utilisez une reproduction complète avec vidéo et captures d'écran étape par étape :

1. Démarrez une vidéo de reproduction avant de reproduire :

agent-browser --session {SESSION} record start {OUTPUT_DIR}/videos/issue-{NNN}-repro.webm

2. Parcourez les étapes à un rythme humain. Faites une pause de 1 à 2 secondes entre les actions pour que la vidéo soit regardable. Prenez une capture d'écran à chaque étape :

agent-browser --session {SESSION} screenshot {OUTPUT_DIR}/screenshots/issue-{NNN}-etape-1.png
sleep 1
# Effectuer l'action (clic, remplissage, etc.)
sleep 1
agent-browser --session {SESSION} screenshot {OUTPUT_DIR}/screenshots/issue-{NNN}-etape-2.png
sleep 1
# ...continuer jusqu'à ce que le problème se manifeste

3. Capturez l'état cassé. Faites une pause pour que le spectateur puisse le voir, puis prenez une capture d'écran annotée :

sleep 2
agent-browser --session {SESSION} screenshot --annotate {OUTPUT_DIR}/screenshots/issue-{NNN}-resultat.png

4. Arrêtez la vidéo :

agent-browser --session {SESSION} record stop

5. Écrivez des étapes de reproduction numérotées dans le rapport, chacune faisant référence à sa capture d'écran.

Problèmes statiques / visibles au chargement (fautes de frappe, texte d'espace réservé, texte tronqué, mauvais alignement, erreurs de console au chargement)

Ces problèmes sont visibles sans interaction — une seule capture d'écran annotée suffit. Pas de vidéo, pas de reproduction en plusieurs étapes :

agent-browser --session {SESSION} screenshot --annotate {OUTPUT_DIR}/screenshots/issue-{NNN}.png

Écrivez une brève description et référez la capture d'écran dans le rapport. Définissez Vidéo de reproduction sur N/A.

---

Pour tous les problèmes :

1. Ajoutez au rapport immédiatement. Ne regroupez pas les problèmes pour plus tard. Écrivez chacun au fur et à mesure que vous le trouvez afin que rien ne soit perdu si la session est interrompue.

2. Incrémentez le compteur de problèmes (ISSUE-001, ISSUE-002, ...).

6. Finaliser

Visez à trouver 5 à 10 problèmes bien documentés, puis finalisez. La profondeur des preuves est plus importante que le nombre total — 5 problèmes avec reproduction complète valent mieux que 20 avec des descriptions vagues.

Après avoir exploré :

1. Relisez le rapport et mettez à jour les comptes de sévérité récapitulatifs pour qu'ils correspondent aux problèmes réels. Chaque bloc ### ISSUE- doit être reflété dans les totaux.
2. Fermez la session :

agent-browser --session {SESSION} close

3. Informez l'utilisateur que le rapport est prêt et résumez les résultats : nombre total de problèmes, répartition par sévérité, et les éléments les plus critiques.

Conseils

• La reproduction est primordiale. Chaque problème a besoin d'une preuve — mais adaptez la preuve au problème. Les bugs interactifs nécessitent une vidéo et des captures d'écran étape par étape. Les bugs statiques (fautes de frappe, texte d'espace réservé, défauts visibles au chargement) nécessitent seulement une capture d'écran annotée.
• Vérifiez la reproductibilité avant de rassembler les preuves. Avant d'enregistrer une vidéo ou de prendre des captures d'écran, vérifiez que le problème est reproductible avec au moins une tentative. S'il ne peut pas être reproduit de manière cohérente, ce n'est pas un problème valide.
• N'enregistrez pas de vidéo pour les problèmes statiques. Une faute de frappe ou un texte tronqué ne bénéficie pas d'une vidéo. Réservez la vidéo pour les problèmes qui impliquent une interaction utilisateur, un minutage ou des changements d'état.
• Pour les problèmes interactifs, capturez chaque étape. Capturez l'avant, l'action et l'après — afin que quelqu'un puisse voir la séquence complète.
• Écrivez des étapes de reproduction qui correspondent aux captures d'écran. Chaque étape numérotée dans le rapport doit référencer sa capture d'écran correspondante. Un lecteur doit pouvoir suivre les étapes visuellement sans toucher au navigateur.
• Utilisez la bonne commande d'instantané.
  • snapshot -i — pour trouver les éléments cliquables/remplissables (boutons, champs, liens)
  • snapshot (sans indicateur) — pour lire le contenu de la page (texte, titres, listes de données)
• Soyez minutieux mais faites preuve de jugement. Vous ne suivez pas un script de test — vous explorez comme le ferait un véritable utilisateur. Si quelque chose semble anormal, enquêtez.
• Écrivez les résultats de manière incrémentielle. Ajoutez chaque problème au rapport au fur et à mesure que vous le découvrez. Si la session est interrompue, les résultats sont préservés. Ne regroupez jamais tous les problèmes pour la fin.
• Ne supprimez jamais les fichiers de sortie. Ne faites pas rm sur les captures d'écran, les vidéos ou le rapport en cours de session. Ne fermez pas la session et ne redémarrez pas. Travaillez en avant, pas en arrière.
• Ne lisez jamais le code source de l'application cible. Vous testez en tant qu'utilisateur, pas en auditeur de code. Ne lisez pas les fichiers HTML, JS ou de configuration de l'application testée. Tous les résultats doivent provenir de ce que vous observez dans le navigateur.
• Vérifiez la console. De nombreux problèmes sont invisibles dans l'interface utilisateur mais apparaissent comme des erreurs JS ou des requêtes échouées.
• Testez comme un utilisateur, pas comme un robot. Essayez des workflows courants de bout en bout. Cliquez sur les éléments qu'un véritable utilisateur cliquerait. Saisissez des données réalistes.
• Saisissez comme un humain. Lorsque vous remplissez des champs de formulaire pendant l'enregistrement vidéo, utilisez type au lieu de fill — il saisit caractère par caractère. Utilisez fill uniquement en dehors de l'enregistrement vidéo lorsque la vitesse compte.
• Ralentissez les vidéos de reproduction pour les humains. Ajoutez sleep 1 entre les actions et sleep 2 avant la capture d'écran du résultat final. Les vidéos doivent être regardables à vitesse 1x — un humain qui examine le rapport doit voir ce qui s'est passé, pas un flou de changements d'état instantanés.
• Soyez efficace avec les commandes. Regroupez plusieurs commandes agent-browser dans un seul appel shell lorsqu'elles sont indépendantes (par exemple, agent-browser ... screenshot ... && agent-browser ... console). Utilisez agent-browser --session {SESSION} scroll down 300 pour le défilement — n'utilisez pas key ou evaluate pour défiler.

Références

Référence	Quand lire
references/issue-taxonomy.md	Début de session — calibrez ce qu'il faut rechercher, niveaux de sévérité, checklist d'exploration

Modèles

Modèle	Objectif
templates/dogfood-report-template.md	Copier dans le répertoire de sortie comme fichier rapport