Qu'est-ce qu'un rapport de bug?

Tester efficacement permet de mettre sur le marché un produit digital de qualité supérieure pour les utilisateurs (découvrez notre Livre Blanc : pourquoi & comment tester à l’ère de la transformation digitale).

Chaque incident repéré lors du test d’un produit digital est répertorié et détaillé dans un rapport de bug afin de disposer d’une base de travail concrète et documentée, ce qui permet aux équipes concernées d’apporter les rectificatifs nécessaires. Il s’agit donc d’un outil de communication, permettant des échanges sains et factuels entre testeurs et équipes chargées d’apporter les correctifs.

Quels sont les éléments constituant un rapport de bug?

Un rapport de bug doit répondre à deux questions clés : quoi ? où ?                                                   

• Quoi : que s’est-il passé ? Quel a été le comportement observé ?
• Où: sur quelle page, quelle fonctionnalité, l’incident a-t-il été détecté ? Dans quel environnement (OS, navigateur, device, url...) ?

Afin de répondre à ces questions, un certain nombre d’éléments doivent être renseignés avec soin par les testeurs.

• Résumé

•  Environnement

Il est nécessaire de donner le plus de détails possibles sur l’environnement, le contexte, dans lequel le bug s’est produit : le navigateur utilisé et sa version, l’OS utilisé et sa version, la marque du device, le modèle…Il faudra aussi renseigner la version du produit testé ainsi que celle de la base de données, mais aussi s’il s’agit de tests réalisés en production, pré-production ou encore en recette.

•  Devices impactés

Quels sont les devices impactés par le défaut ?

•  Description du comportement observé

La nature du défaut doit être clairement expliquée. Si un développeur examinant le défaut ne peut pas comprendre les détails le concernant, il est alors fort probable que le rapport sera renvoyé au testeur afin qu’il soit complété avec plus d’explications et de détails, ce qui causera des retards dans le traitement du défaut. La description doit donc contenir toutes les étapes nécessaires pour reproduire le bug, ainsi que l’étape à laquelle le défaut s’est produit. Lorsque cette partie est bien complétée, aucun aller-retour entre les équipes de tests et celles chargées d’apporter les rectificatifs n’est nécessaire, ce qui permet d’avoir des temps de correction plus rapides.

•  Description du comportement attendu

Il est important que la description du comportement attendu par rapport au comportement obtenu lors des tests soit ajoutée, afin de faciliter la compréhension du défaut et de ses conséquences par les équipes chargées des rectificatifs.

•  Reproductibilité

Mentionner si le bug trouvé est reproductible mais également son occurrence (le bug se reproduit-il à chaque fois?).

•  Gravité

La gravité du défaut permet de comprendre l’incidence que le défaut aura sur les systèmes et le business. La gravité est évaluée par le testeur et est généralement donnée sur une échelle de 3 niveaux, choisis par chaque organisation.

 - Bloquant: le défaut peut potentiellement causer de graves dégâts et il n’y a pas de solution pour contourner ce problème. Par exemple : une application ne s’ouvre pas, et cause une fermeture de l’OS.

- Majeur: des fonctionnalités majeures de l’application manquent ou ne fonctionnent pas et il n’y a pas de solution pour contourner ce problème. Par exemple : une application n’affiche pas certains formats d’images.

 - Mineur: des fonctionnalités de l’application ne fonctionnent pas ou un défaut cause une gêne mais une solution existe pour contourner le problème et elle peut être utilisée comme solution temporaire. Par exemple : l’utilisateur doit cliquer deux fois sur un bouton GUI (graphic user interface) pour déclencher l’action voulue.

•  Type d’incident

Les incidents doivent également être classifiés par type : textuel, graphique, fonctionnel, technique et ergonomique. Une organisation peut également choisir d’ajouter une classification supplémentaire : les suggestions. Cela permettra alors aux testeurs d’apporter des suggestions d’amélioration. Par exemple : un testeur peut souhaiter proposer l’amélioration d’un éléments GUI (Graphic User Interface).

• Priorité

Une fois que la gravité du bug trouvé a été déterminée, il s’agit ensuite de prioriser la mise en œuvre de la correction. La priorité sert donc à déterminer la rapidité à laquelle le défaut doit être réparé. Cela est déterminé en fonction de l’importance de l’impact business du défaut. La priorité est également souvent catégorisée en 4 ou 5 niveaux, allant de haut (la correction doit être apportée immédiatement) à bas (la correction peut être apportée lors d’une prochaine mise en production).

Un défaut ayant une gravité élevée aura également un niveau de priorité haut. Ainsi, un défaut critique aura une priorité haute afin d’être résolu le plus rapidement possible.

Il ne peut pas y avoir de défaut ayant une gravité élevée sans priorité élevée. En revanche, un défaut peut avoir une faible gravité mais une priorité élevée. Par exemple, un texte peut contenir des fautes d’orthographe : la gravité ne sera pas critique dans le sens où de graves dégâts ne seront pas causés d’un point de vue technique. Par contre, d’un point de vue réputation et image de marque, cette erreur sera à résoudre rapidement.

Dans le cas où une organisation fait appel à un prestataire externe pour réaliser ses tests, cette partie sera en général pilotée par le client directement. Les chefs de projets ou product owners prioriseront alors en interne les défauts, en fonction de leur vision du produit et de l’impact business potentiel.

•  Pièce jointes

Les preuves des défauts doivent être enregistrées et faire partie du rapport. Ces explications visuelles sont clés : elles permettent de justifier les anomalies rencontrées et de les documenter et donnent au développeur le moyen de mieux comprendre la situation. Il est donc recommandé d’ajouter au rapport des logs, des rapports de crash, ou encore des vidéos et des captures de chaque étape exécutée lors des phases de tests et pour chaque anomalie.

Apporter une attention particulière aux rapports de bugs lors des phases de tests permet d’optimiser le temps passé par la suite par les développeurs pour y apporter les correctifs nécessaires. Cela permet aussi de constituer une base de données sur laquelle se baser pour établir des KPIs indispensables au monitoring des phases de test (voir notre article : Applications mobiles & KPIs).

Et pour aller plus loin, découvrez notre outil de gestion de campagne de test, BugTrapp :