bughunt

Que fait bughunt ?

Les tests unitaires et la plupart des tests d'interface vérifient les chemins de code auxquels leurs auteurs ont pensé, souvent via des hooks de test qui contournent les vrais clics et frappes. Les gens n'utilisent pas une application de cette façon. Ils cliquent là où le hook ne va pas, appuient sur Annuler après chaque action, travaillent dans une fenêtre étroite, perdent le réseau en cours de route et ouvrent le fichier étrange envoyé par un collègue. La plupart des bugs qu'ils rencontrent étaient déjà là, et personne ne regardait.

Cette compétence regarde. Elle pilote la vraie application avec de vraies entrées, une zone à la fois, et enregistre chaque bug confirmé deux fois : comme un test échouant qui reste dans le dépôt, afin que le bug ne puisse pas revenir inaperçu, et comme une entrée dans la liste de bugs du dépôt, afin que quelqu'un le corrige. Une chasse ne corrige pas le code du produit. Elle trouve, prouve et écrit.

Modes

• Hunt (par défaut) : choisir une zone, la chasser, enregistrer les résultats, mettre à jour la rotation. Une zone par exécution permet à une chasse d'être assez approfondie pour trouver de vrais bugs.
• Set up : le dépôt n'a aucun moyen de piloter l'application de bout en bout, ou il manque les limites dans references/boundaries.md. Construire le plus petit couloir de parcours qui peut exécuter une fonctionnalité sur chaque surface (references/walkthroughs.md), puis chasser.
• Sweep : exécuter tous les parcours existants et signaler ce qui est nouveau, ce qui a changé et ce qui a été corrigé depuis la dernière exécution. Un sweep trouve des régressions, pas de nouveaux types de bugs ; à associer avec des chasses.
• Rules : ajouter l'une des règles de references/invariants.md au couloir, afin qu'elle s'exécute à chaque étape de chaque parcours. Une seule règle (par exemple « Annuler restaure l'état précédent exact ») peut révéler une douzaine de bugs dans des fonctionnalités pour lesquelles personne ne penserait à écrire un script.

1. Apprendre d'abord les règles de base

Lire les fichiers d'instructions du dépôt (CLAUDE.md, AGENTS.md, CONTRIBUTING, toutes les règles ou notes de passation), le README de ce qui exécute l'application, et les tests de bout en bout existants. Découvrir :

• Comment démarrer chaque surface de l'application : serveur de développement, build desktop, simulateur mobile. Une surface est un hôte (web, desktop, mobile) avec une apparence (clair, sombre, contraste élevé) à une taille (large, étroite, téléphone).
• Où les bugs sont suivis (un fichier de bugs, une liste de tâches, un suivi de tickets) et le format des entrées utilisées là-bas. Écrire dans ce format.
• Ce qu'un test ne doit jamais toucher : vrais comptes, vrais fichiers utilisateur, données de production, vrais e-mails, paiements, le presse-papiers de l'utilisateur, l'imprimante et le navigateur, la copie installée de l'application. Lire references/boundaries.md et mettre en place chaque limite applicable avant de piloter quoi que ce soit. C'est la partie d'une chasse qui peut faire de vrais dégâts, donc elle vient en premier.
• Si le dépôt interdit autre chose (push, accès réseau, services payants, lancement d'agents). Ces règles l'emportent sur cette compétence.

Ne demander que lorsque la réponse change ce que vous pouvez toucher. Sinon, choisir et écrire l'hypothèse dans le rapport de chasse.

2. Choisir la zone et lister ce qu'elle fait

Utiliser la zone nommée par la personne. Sinon, lire bughunt/areas.md (le créer à partir de templates/areas.md lors de la première exécution) et choisir, dans cet ordre : une zone jamais chassée, puis une zone modifiée depuis sa dernière chasse (git log sur ses chemins), puis la plus ancienne. Une zone est un ensemble de fonctionnalités qu'une personne utilise ensemble : l'éditeur de documents, le navigateur de fichiers, la connexion et les comptes, les paramètres, le partage, les paiements.

Lister les fonctionnalités de la zone à partir de ce que le dépôt contient : un registre de fonctionnalités, les menus et la liste des commandes, les routes, les pages d'aide, les points d'entrée du code. Chaque fonctionnalité reçoit au moins un passage sur chaque surface.

3. Chasser

Pour chaque fonctionnalité, faire d'abord ce qu'une personne fait avec elle, du début à la fin, sur des fichiers synthétiques réalistes. Puis parcourir references/checklist.md. C'est une liste de mouvements d'utilisateur hostile qui cassent les applications encore et encore : Annuler après chaque étape, clavier uniquement, fenêtre étroite, mode sombre, déconnexion en cours, le fichier le plus gros et le plus cassé, un aller-retour via un autre format, la même chose dans deux onglets, un échec volontaire.

Piloter l'application avec de vrais événements d'entrée (clics, pressions de touches, glissés, saisie) au rythme d'une personne. Un script agit plus vite qu'une personne, donc laisser un court battement après un clic avant l'action suivante, et laisser une demi-seconde entre deux changements que vous prévoyez d'annuler séparément. Sinon, vous classerez des artefacts de timing comme des bugs.

Observer chaque étape pour :

• le mauvais résultat, ou un bon résultat qui ne persiste pas (disparu après rechargement, sauvegarde, Annuler ou changement d'onglet)
• du travail perdu : modifications, paramètres, sélection, position de défilement
• Annuler qui enlève trop, trop peu, ou rien
• une commande qui ne fait rien, ne fonctionne qu'à partir d'un de ses points d'entrée, ou n'est pas désactivée quand elle ne peut pas s'exécuter
• du texte d'erreur brut : traces de pile, codes d'erreur, chemins internes
• erreurs console, plantages, fenêtres vides, blocages
• du texte trop pâle, tronqué, qui se chevauche, ou coupé au milieu d'un mot (les vérifications de capture d'écran dans references/invariants.md détectent la plupart de ces problèmes automatiquement)
• la même étape se comportant différemment sur une autre surface

Noter chaque candidat dès que vous le voyez, avec la surface, l'étape et ce que vous attendiez. Puis continuer ; confirmer à la fin de la fonctionnalité.

4. Confirmer avant de classer

Une chasse n'est aussi bonne que ses résultats sont vrais. Pour chaque candidat :

1. Le reproduire deux fois à partir d'un état propre, au rythme d'une personne, à la main ou avec un script minimal. S'il ne se reproduit pas, l'abandonner ou le classer comme « Non vérifié : » avec ce que vous avez vu et où.
2. Éliminer le test. Le timing (voir ci-dessus), un sélecteur qui a correspondu au mauvais élément, les propres bouchons du test, une fenêtre qui n'était pas focalisée, le pointeur reposant sur quelque chose avec un état de survol. Un résultat qui va et vient avec la position du pointeur est réel mais nécessite une position de pointeur fixe dans son test.
3. Trouver la cause quand c'est peu coûteux. Lire le code à l'endroit probable et nommer le fichier et la fonction. Ne pas y passer trop de temps ; le correcteur le fera.
4. Vérifier le suivi. Si une entrée couvre déjà le bug, ajouter la nouvelle surface ou le nouveau détail à cette entrée plutôt que d'en créer une nouvelle.
5. Grouper par cause. Plusieurs symptômes partagent souvent une cause unique (une seule liaison de touche manquante peut casser Annuler dans cinq éditeurs sur un même hôte). Le dire, afin que la correction ait lieu une fois.

5. Enregistrer chaque bug confirmé

• D'abord un test échouant. Ajouter une étape au parcours de la fonctionnalité (ou un nouveau parcours) dont l'attente énonce ce qui devrait se produire. L'exécuter et vérifier qu'il échoue, et qu'il échoue pour la raison du bug, pas pour autre chose. Il passe une fois le bug corrigé. Ne jamais affaiblir une attente existante ou une vérification de capture d'écran pour faire passer une exécution. Si une vérification est erronée, dire pourquoi dans le rapport et la laisser pour une personne.
• Puis l'entrée de bug, à la fin de la liste de bugs du dépôt, dans son format, en utilisant templates/bug-entry.md : le symptôme dans les mots d'un utilisateur, ce qui se produit contre ce qui devrait, les chiffres mesurés, où dans le code, quel test la protège, et sur quelles surfaces elle apparaît.
• Aucune modification du code du produit dans une chasse, sauf si la personne a demandé des corrections. Corriger au fur et à mesure cache les résultats et mélange deux types de relecture.
• Commiter les nouveaux tests et les entrées de bugs si les règles du dépôt le permettent, en organisant les fichiers par nom. Ne pas pousser sauf si la personne l'a dit.

6. Rapporter et tourner

Écrire le rapport de chasse à partir de templates/hunt-report.md : la zone, les surfaces, chaque résultat avec son test et son entrée, les candidats abandonnés et pourquoi, ce que vous n'avez pas pu tester, et les groupes de correction suggérés par cause. Mettre à jour la ligne de la zone dans bughunt/areas.md (date, commit, résultats).

Terminer en disant à la personne, en langage clair : combien de bugs ont été confirmés, les trois pires, les groupes de correction, et la prochaine zone que la rotation choisirait.

Continuer à en trouver

Une chasse terminée laisse des tests qui attrapent les mêmes bugs s'ils reviennent. De nouveaux bugs nécessitent de nouveaux regards :

• Chasser à nouveau en rotation. Re-chasser une zone après des changements importants.
• Transformer un bug qui réapparaît dans de nouveaux endroits en règle (references/invariants.md) afin que chaque étape le vérifie.
• Chaque bug signalé par une personne devient une étape de parcours avant d'être corrigé.
• Exécuter tout le couloir avant chaque publication et, si le dépôt permet un planificateur, chaque nuit. Ne signaler que les échecs nouveaux et changés, afin qu'un bug connu n'en enterre pas un nouveau.

Quand le travail est important

Si vous pouvez répartir le travail entre modèles ou sessions, chasser avec votre modèle le plus fort et confirmer avec un modèle différent dans une session fraîche. Le deuxième passage réexécute chaque test échouant à partir d'un état propre et lit chaque entrée à froid. Cela attrape le faux positif confiant qu'un seul passage a tendance à conserver.