Comment créer un bon ticket de bug ?

Une des principales tâches du testeur est de créer des tickets de bugs. On en rédige tous les jours (ou presque), tout le monde est amené à en lire. Je propose donc de répondre ici à cette question : 

« Comment créer un bon ticket de bug ? »

Les caractéristiques primordiales d’un bon ticket sont :

• Être précis dans la reproduction du problème : imaginez qu’une personne qui ne connaît rien au système lise votre ticket. Cette personne doit être capable de reproduire le bug.
• Être précis dans le résultat attendu : ce qui est implicite est source de malentendu. Pour cela, dites clairement ce que le système devrait faire.

Pour répondre à ces besoins, je standardise toujours le template de mes tickets de bug. Il ressemble grosso modo à ceci:

1. Titre
2. (Optionnel) Description succincte
3. Procedure (étape par étape + résultat obtenu)
4. Résultat attendu
5. (Optionnel) Détails supplémentaires
6. Configuration
7. Priorité

Le titre doit être court (5-6 mots maximum) mais suffisamment explicite pour comprendre le problème. Par exemple, on préfèrera un « Title of graph TOTO not aligned horizontally » à un «  Bug on graph TOTO ». Dans le premier cas, on comprend qu’il s’agit d’un problème de design (et donc potentiellement, à faible impact), alors que dans le second, on ne sait pas dire si le problème est grave ou pas.

La procédure est le point essentiel du ticket. Elle va permettre au développeur de gagner un temps précieux puisqu’il saura exactement comment reproduire le problème. Pour cela, je conseille de ne pas être avare en détails. Préférez une procédure comme ceci :

• Click on the button settings
• Swipe on the right to reach the Profile tab
• Fill « Frédéric » in the field ’Name’
• Validate ==> find that the displayed name is « Fr_d_ric » 

Plutôt que ce genre de procédure :

• If I change the username to « Frédéric », it is not well displayed 

Par expérience, ces quelques minutes de perdues dans la rédaction du ticket seront des heures de gagnées. Dans notre cas ci-dessus, à la lecture de la procédure, le développeur peut déjà comprendre que le problème vient des accents. Il n’aura potentiellement même pas besoin de reproduire le problème lui même, et il saura beaucoup plus facilement où aller corriger le problème dans sa codebase. N’hésitez pas à inclure des screenshots (ou des films) du problème : cela confirme au développeur ce que vous avez observé, et cela permet de gagner du temps lorsqu’on présente le ticket en réunion (backlog refinement, etc…).

Je le répète, ce qui est implicite est source de malentendu. Ecrivez donc quel est le résultat attendu, même si dans 90% des cas, ce sera évident. L’expérience montre que la solution imaginée n’est pas toujours celle implémentée par le développeur.

Un ticket ne saurait être complet sans une configuration associée. Indiquez toujours quel téléphone vous avez utilisé, son OS, quel navigateur web, quelle version de votre application… Cette information ne sera peut être pas utile pour le développeur dans de nombreuses situations. Mais si vous ne l’avez pas notée, et que vous en avez besoin, vous vous maudirez quand vous devrez refaire la procédure sur 5 appareils pour retrouver le fautif… https://www.monkeyuser.com/2017/future-self/

Enfin, un ticket a souvent une priorité. Chaque entreprise catégorise à sa manière (mandatory/major/minor, high/medium/low, 1/2/3, etc…). Adaptez vous aux pratique de l’entreprise pour être homogène avec les autres tickets.

Dans certains cas, on peut rajouter une description au début du ticket. Cela peut être utile pour donner du contexte,   pour expliciter un titre ou une procédure pas assez claire, etc… De la même manière, j’ajoute parfois une étape « Détails supplémentaires » lorsque je veux soulever un point qui ne rentre nulle part ailleurs (le problème ne se produit que sur certains graphiques, la même procédure mais en remplaçant telle étape par une autre donne tel résultat, etc…).

Merci pour votre lecture, et n’hésitez pas à réagir en commentaires !