Rédiger un rapport de bug, aussi appelé relevé de bogue, peut sembler facile. Tout le monde peut rapporter un bug mais ce n’est pas tout le monde qui prend le temps de le rapporter de manière efficace. Pour être efficace, un rapport de bug doit être méthodique et contenir certains éléments clés et c’est ce que nous verrons dans cet article.
Rédiger un rapport de bug efficacement
If a tester is not reporting a bug correctly, the programmer will most likely reject this bug stating it as irreproducible.
softwaretestinghelp.com
Cette citation illustre l’importance d’un bon rapport de bug. À mon avis, il s’agit du meilleur argument pour prendre conscience de l’importance de celui-ci. J’ai travaillé dans des environnements où les rapports de bugs étaient très efficaces et bien structurés. Il était très facile de comprendre, cerner et régler le bogue, faisant en sorte que les utilisateurs voyaient rapidement les améliorations au système.
Pouvez-vous reproduire l’erreur plusieurs fois?
Repérer un bug c’est pouvoir le reproduire plusieurs fois en obtenant le même résultat (différent du résultat attendu, évidemment!). En général, on s’entend pour dire que si vous êtes en mesure de reproduire le même bug à 3 reprises, vous avez repéré un bug.
Les objectifs
- Les objectifs principaux du rapport de bogue sont :
-
- repérer un bogue spécifique et reproductible
- l’expliquer au(x) développeur(s)
L’expression « bogue spécifique », dans le premier point, veut dire qu’il s’agit d’une action ou d’un élément précis, comme par exemple soumettre le formulaire ABC ou la couleur de l’en-tête de la page XYZ. Cette information va aider grandement dans l’explication aux développeurs : Prenez le temps de dire à quel endroit vous vous trouvez dans l’application ou le site, avec un URL c’est encore mieux, et expliquer étape par étape comment reproduire le bogue. Ensuite, décrivez le résultat obtenu et rappelez le résultat attendu.
Meilleures pratiques
- Assurez-vous que le bogue est reproduisible;
- Évitez de dupliquer un bogue, rechercher les archives avant d’écrire un nouveau rapport;
- Testez toujours (3 fois plutôt qu’une) sur la version la plus récente de l’application ou site;
- Un seul bogue par rapport (ça semble évident mais parfois, on a tendance à s’étendre sur plusieurs bogues en même temps (fonctionnel et visuel par exemple);
- Écrivez un bon sommaire et concentrez-vous sur les faits, non les opinions ou les plaintes;
- Reliser votre rapport avant de le soumettre;
- Assurez-vous de rapporter les bogues/failles de sécurité dans un environnement privé (ne dites pas haut et fort que l’application est vulnérable publiquement);
- Identifier le bogue avec un numéro ou autre pour fins de références futures.
Le contenu d’un rapport
- Sommaire – Intituler le bogue d’une manière précise et unique;
- Description – Expliquer le bogue aux développeurs;
- Étapes pour reproduire – Expliquer étape par étape comment reproduire le bogue;
- Résultat obtenu – Ce qui est arrivé;
- Résultat attendu – Ce qui doit arriver;
- Scénario de test réduit à son maximum;
- Environnement et/ou configuration particulière (e.g. identifiant du « Build », « OS », etc.);
- Version du navigateur;
- Tout autre information pertinente.
Un document de haute qualité
Le travail du rapport de bug consiste donc à rapporter exactement le problème. Votre rapport de bug doit être un document de haute qualité, clair, concis et contenir tous les éléments clés afin que les développeurs puissent l’identifier et le corriger dans le plus bref délai.
Si vous avez besoin d’aide pour mettre en place un gabarit pour vos rapports de bugs, n’hésitez pas à communiquer avec nous.
- Ressources externes :
-
- Etemad, Elika J., « How to File a Good Bug Report », 15 juin 2012
- Kirch, Julien, « Comment signaler efficacement un bug », 1999
- Vijay, « How to Write a Good Bug Report? Tips and Tricks », 26 mars 2018
