Un rapport de bug n’a qu’une seule tâche : permettre à quelqu’un qui n’a jamais vu le problème de le reproduire du premier coup. La plupart échouent là, et rarement faute d’efforts. Ils échouent à cause d’une poignée d’habitudes, répétées par des gens soigneux qui n’ont jamais vu leur propre rapport atterrir sur le bureau de quelqu’un d’autre.
Chaque détail omis coûte des secondes à écrire et des heures à récupérer : un aller-retour dans un fil de commentaires, un développeur qui reconstruit un état où vous étiez déjà assis, un ticket fermé comme non reproductible et rouvert quinze jours plus tard par quelqu’un d’autre. Vous êtes la seule personne à qui ce contexte ne coûtera jamais rien.
Dix habitudes, en deux groupes. Les six premières relèvent du jugement, et aucun outil ne les fera jamais à votre place. Les quatre dernières sont du contexte qui existait au moment du bug et que personne n’a noté.
- Un titre qui décrit un ressenti
- Aucune étape de reproduction
- Aucun comportement attendu
- Plusieurs bugs dans un seul ticket
- De l’émotion à la place de l’impact
- Ne pas chercher les doublons
- Oublier l’environnement
- Décrire ce que vous avez vu au lieu de le montrer
- Passer à côté de la console et de l’onglet réseau
- « Ça marche chez moi », sans rien joindre
Si vous cherchez la méthode plutôt que les pièges, l’article compagnon sur comment écrire un rapport de bug parfait en donne l’anatomie.
Ce que vous seul pouvez écrire
1. Un titre qui décrit un ressenti
« Le paiement est cassé. » « La connexion ne marche pas. » « Il y a un souci avec les images. »
Un titre est lu de nombreuses fois et ouvert une seule. Il apparaît dans les résultats de recherche, dans les points d’équipe, dans les notes de version et dans la liste que quelqu’un parcourt en décidant ce qu’il prend ce matin. Un titre qui pourrait décrire quarante défauts différents rend chacun de ces moments plus lent.
Le schéma, c’est ce qui a cassé, plus où ou quand, plus le seul détail qui distingue votre cas de celui de tous ceux chez qui ça fonctionne.
- Faible
- Images cassées
- Meilleur
- Les images produit ne se chargent pas sur Chrome mobile quand la page est ouverte depuis la recherche
Visez une phrase que quelqu’un pourrait répéter à voix haute sans ouvrir le ticket.
2. Aucune étape de reproduction
Sans étapes, un développeur ne débogue pas, il devine ce que vous avez fait. Chaque mauvaise
supposition finit en cannot reproduce, le ticket vous revient, et le chronomètre repart.
Les étapes doivent partir d’un état que n’importe qui peut atteindre.
- Faible
- Va dans mon panier et essaie de payer
- Meilleur
- 1. Se connecter comme client avec un panier vide. 2. Ajouter deux articles quelconques. 3. Appliquer le code SAVE10. 4. Cliquer sur Continuer vers le paiement.
Quatre lignes, et le lecteur se tient là où vous vous teniez. Donnez vos propres étapes à un collègue qui n’a pas vu le bug. S’il revient avec une question, la question est votre étape manquante.
3. Aucun comportement attendu
« Le total est faux » suppose que le lecteur sait à quoi ressemble le juste. Souvent il ne le sait pas, et parfois ce que vous signalez se révèle être une règle que vous ignoriez.
Écrivez les deux moitiés.
- Faible
- La remise est fausse
- Meilleur
- Attendu : le total affiche 45,00 après la remise de 10 %. Constaté : le total affiche 50,00 et la ligne de remise est absente.
C’est aussi comme cela que vous découvrez que le développeur et vous n’êtes pas d’accord sur ce à quoi sert la fonctionnalité, une conversation qu’il vaut mieux avoir dans le ticket que trois semaines plus tard.
4. Plusieurs bugs dans un seul ticket
Déposer trois problèmes ensemble donne une impression d’efficacité. C’en est une fausse, car un ticket n’a qu’un état. Quand deux des trois sont corrigés, le ticket n’est ni fait ni à faire, et le troisième problème disparaît discrètement sous une discussion qui se lit comme close.
Un défaut par ticket. S’ils partagent une cause, dites-le et reliez-les.
5. De l’émotion à la place de l’impact
« C’est inutilisable. » « Comment ça a pu sortir ? » « Troisième fois cette semaine. »
L’agacement est légitime. Un bug vient d’avaler votre après-midi. Mais il chasse l’information qui ferait corriger la chose, et il met le lecteur sur la défensive précisément quand vous avez besoin de son attention sur le problème.
L’impact a sa place dans un rapport de bug. Énoncez-le comme un fait, et donnez à celui qui trie de quoi fixer une priorité sans deviner : combien de personnes sont touchées, à quelle fréquence, si de l’argent ou des données sont en jeu, s’il existe un contournement, et si cela fonctionnait avant.
- Faible
- C'est une catastrophe, corrigez au plus vite
- Meilleur
- Bloque le paiement pour tous les clients Safari, aucun contournement, apparu après la version de mardi
Le second est bien plus alarmant que le premier, et bien plus susceptible d’être pris aujourd’hui. Un bug qui empêche une personne de changer son avatar et un bug qui empêche tous les clients de payer ne devraient jamais arriver avec la même allure.
6. Ne pas chercher les doublons
Les doublons coûtent deux fois : une première quand quelqu’un trie un rapport déjà connu, et une seconde quand la discussion d’un même problème est répartie sur deux tickets dont aucun ne contient toute l’histoire.
Cherchez dans l’outil de suivi le message d’erreur, le nom de la page, et un mot ou deux du titre que vous alliez écrire. Cherchez aussi dans les tickets fermés, car un bug corrigé qui revient est une régression, et le dire change la façon dont il est traité.
Chercher est aussi le moyen le plus rapide d’apprendre les mots que votre équipe emploie vraiment. Si tout le monde dit corbeille et que vous dites panier, votre rapport ne sera pas trouvé par la prochaine personne qui cherchera, et vous ne trouverez pas le sien.
Ce que le navigateur sait déjà
Les quatre suivantes sont d’une autre nature. Personne n’omet une version de navigateur pour s’épargner un effort. On l’omet parce que la noter suppose de quitter la page, de traquer une chaîne de version et de la taper dans un formulaire, et qu’à ce moment-là l’onglet est fermé.
7. Oublier l’environnement
Un bug qui survient partout et un bug qui survient dans un seul navigateur sont deux bugs différents aux causes différentes, et personne ne peut dire lequel vous avez avant que quelqu’un vérifie. C’est ainsi qu’un rapport est fermé comme non reproductible : le développeur a essayé dans Chrome, et vous étiez dans Safari.
Notez le navigateur et sa version, le système d’exploitation, l’appareil, et la taille de la
fenêtre dès que la mise en page entre en jeu. Latest Chrome n’est pas une version. Cela veut
dire autre chose le jour où on le lit que le jour où on l’a écrit.
8. Décrire ce que vous avez vu au lieu de le montrer
La prose est un format avec pertes pour un problème visuel. « La mise en page devient bizarre plus bas » peut vouloir dire une demi-douzaine de choses, et cette demi-douzaine a des correctifs différents.
Une copie d’écran règle d’un coup les problèmes de mise en page et de texte. Un court enregistrement vaut mieux pour tout ce qui touche au timing, à l’animation ou à une suite d’interactions. Capturez la fenêtre entière plutôt qu’un recadrage de la partie cassée : la barre d’adresse, la console et la page autour contiennent souvent la réponse.
9. Passer à côté de la console et de l’onglet réseau
C’est la première chose qu’un développeur demande et la dernière que la plupart des rapports contiennent. Une erreur rouge dans la console nomme le plus souvent le fichier et la ligne en faute. Une requête échouée dans l’onglet réseau nomme le plus souvent le code de statut et le point d’accès. L’une ou l’autre peut transformer un après-midi de bissection en un correctif de deux minutes.
Ouvrez les outils de développement avant de fermer l’onglet. Copiez le texte de l’erreur plutôt que de le photographier, pour qu’il reste cherchable. Si une requête a échoué, notez son statut et son chemin.
10. « Ça marche chez moi », sans rien joindre
La phrase termine une conversation sans rien résoudre, et elle joue dans les deux sens. D’un développeur, elle veut dire que le rapport manquait du détail permettant de reproduire. D’un rapporteur, répondre à un correctif par « c’est toujours cassé chez moi » et rien d’autre veut dire exactement la même chose en sens inverse.
Dans les deux cas la réponse est une preuve plutôt qu’une affirmation : la version testée, l’environnement dans lequel vous l’avez testée, et ce que vous avez vu. Un rapport sur un correctif raté mérite le même soin que le rapport d’origine.
Ce qui règle vraiment la moitié de tout cela
Reprenez le second groupe. Les erreurs 7, 8, 9 et 10 sont un seul problème sous quatre casquettes : le contexte existait au moment du bug, et personne ne l’a noté.
C’est la partie qui mérite d’être automatisée, et c’est pour cela que nous avons construit Session Replay.
Session Replay
Extension Chrome gratuite. Un clic sur la page qui se comporte mal capture la copie d'écran, la console et le journal réseau, et vous rend un lien à coller dans le ticket.
Elle ne sait pas sur quoi vous avez cliqué. Elle sait ce que le navigateur savait. Elle n’écrira donc pas votre titre, ne découpera pas vos trois bugs en trois tickets et ne vous dira pas ce que vous attendiez. Cela relève du jugement, et cela reste le vôtre. Ce qu’elle supprime, c’est l’excuse des quatre habitudes qui n’ont jamais tenu qu’à de la friction, ce qui vous laisse les six qui tiennent à penser clairement.
La liste de contrôle
Avant d’appuyer sur envoyer :
- Le titre nomme ce qui a échoué, où, et dans quelle condition
- Les étapes partent d’un état que n’importe qui peut atteindre
- Le comportement attendu et le comportement constaté sont tous deux écrits
- Un défaut dans ce ticket, et un seul
- L’impact énoncé comme un fait, avec de quoi laisser un autre fixer la priorité
- J’ai cherché un rapport existant dans les tickets ouverts et fermés
- Le navigateur, sa version, le système d’exploitation et l’appareil sont notés
- Une copie d’écran ou un enregistrement est joint, montrant la fenêtre entière
- Les erreurs de console et les requêtes échouées sont recopiées en texte
- Une preuve pour tout ce que j’affirme, y compris « ça se produit encore »