Rapporter un bug
Quiconque a déjà développé un logiciel destiné à un usage public a probablement déjà reçu au moins un mauvais rapport de bug. Il y a les rapports qui ne disent rien (« Ça ne marche pas ! »), qui n’ont aucun sens, qui ne donnent pas assez d’informations, ou même qui donnent de fausses informations. Il y a des comptes-rendus de problèmes qui sont dus à des erreurs de l’utilisateur, dus à une mauvaise configuration du système, ou dus à des problèmes de fichier ou de réseau.
Si le programme ne fonctionnait pas du tout, son développeur s’en serait probablement déjà rendu compte. Comme il n’a rien remarqué, pour lui, il doit fonctionner. Donc, soit vous faites quelque chose d’une autre manière que lui, ou votre environnement est différent du sien. Il a besoin d’informations ; lui fournir ces informations est l’objectif d’un rapport de bug.Si le programme plante spécifiquement sur un seul fichier, vous devrez en envoyer une copie. Le développeur voudra connaître le maximum de détails sur votre ordinateur, pour pouvoir travailler sur ce qui le différencie du sien. Les numéros de versions seront une chose à préciser : le numéro de version du programme et celui du système d’exploitation.
Le but d’un rapport de bug est de permettre au programmeur de voir le programme planter devant lui. Vous pouvez soit lui montrer de visu (screencast), soit lui fournir des instructions soignées et détaillées sur la façon de le faire planter. S’il parvient à le faire planter, il essaiera de collecter des informations jusqu’à découvrir la cause du bug. S’il n’y parvient pas, il devra vous demander d’obtenir ces informations pour lui. Alors dites exactement ce que vous avez fait : dites sur quels boutons vous avez cliqué, et dans quel ordre. Si le programme plante spécifiquement sur un seul fichier, vous devrez en envoyer une copie.
Quelques recommandations
- Soyez spécifique
Si vous pouvez faire une chose de deux manières différentes, indiquez celle que vous avez utilisée. « J’ai sélectionné Ouvrir » peut signifier « J’ai cliqué sur Ouvrir » ou « J’ai appuyé sur Ctrl+O ». Ça peut sembler inutile, mais parfois, ça compte. - Soyez prolixe
Donnez plutôt plus d’informations que moins. Si vous en dites trop, le programmeur pourra en ignorer une partie, mais si vous n’en dites pas suffisamment, il devra vous répondre en vous posant d’autres questions. - Faites attention aux pronoms
N’utilisez pas des mots comme « il », ou des références comme « la fenêtre » quand leur signification est imprécise. Considérez l’exemple suivant : « J’ai lancé l’application Echosync. Elle a affiché une fenêtre d’erreur. J’ai essayé de la fermer et elle a planté ». Quel élément l’utilisateur a-t-il bien pu essayé de fermer ? S’agit-il de la fenêtre d’erreur ou de toute l’application ? Ça fait une différence ! Au lieu de cela, dites plutôt : « J’ai lance l’application Echosync. Elle a affiché une fenêtre d’erreur. J’ai essayé de fermer la fenêtre d’erreur et Echosync a planté ». C’est plus long et répétitif, mais également plus clair et moins susceptible d’être compris de travers. - Relisez ce que vous avez écrit
Relisez le rapport et voyez si vous pensez qu’il est clair. Si vous avez fait une liste des actions qui devraient produire le bug, essayez de la suivre, et vérifier ainsi qu’aucune étape ne manque.
Synthèse
Le premier objectif d’un rapport de bug est de permettre au programmeur de voir le bug de ses propres yeux. Si vous ne pouvez le faire planter devant lui, à l’aide d’une vidéo par exemple (screencast), donnez lui des instructions détaillées afin qu’il puisse le faire planter par lui-même.
Si le premier objectif ne peut être atteint, et donc si le programmeur ne peut voir l’erreur se produire, le second objectif d’un rapport de bug est de décrire ce qui s’est mal passé. Décrivez tout, en détails. Dites ce que vous avez vu, mais dites aussi ce que vous vous attendiez à voir. Recopiez les messages d’erreur, ou faîtes-en une capture d’écran (screenshot).