Pourquoi un bon rapport de bug ?

Si votre rapport de bug est efficace, alors ses chances d’être corrigé sont plus élevées. Ainsi, la correction d’un bug dépend de l’efficacité avec laquelle vous le signalez. Rapporter un bug n’est rien d’autre qu’une compétence et je vais expliquer comment atteindre cette compétence.

« L’intérêt d’écrire un rapport de problème (rapport de bug) est de faire corriger les bugs » – Par Cem Kaner. Si un testeur ne rapporte pas un bug correctement, le programmeur rejettera très probablement ce bug en le déclarant irreproductible.

Cela peut blesser le moral des testeurs et parfois l’ego aussi. (Je suggère de ne pas garder n’importe quel type d’ego. Les ego comme « J’ai rapporté le bug correctement », « Je peux le reproduire », « Pourquoi il/elle a rejeté le bug ? », « Ce n’est pas ma faute » etc.,).

Quelles sont les qualités d’un bon rapport de bug logiciel ?

Tout le monde peut écrire un rapport de bug. Mais tout le monde ne peut pas écrire un rapport de Bug efficace.

Vous devez être capable de distinguer un rapport de Bug moyen d’un bon rapport de Bug. Comment faire la différence entre un bon et un mauvais rapport de bug ? C’est très simple, appliquez les caractéristiques et les techniques suivantes pour signaler un bug.

Les caractéristiques et les techniques comprennent

#1) Avoir un numéro de bug clairement spécifié : Attribuez toujours un numéro unique à chaque rapport de bug. Ceci, à son tour, vous aidera à identifier l’enregistrement du bug. Si vous utilisez un outil automatisé de signalement des bogues, alors ce numéro unique sera généré automatiquement chaque fois que vous signalerez le bogue.

Notez le numéro et une brève description de chaque bogue que vous avez signalé.

#2) Reproductible : Si votre bogue n’est pas reproductible, alors il ne sera jamais corrigé.

Vous devez clairement mentionner les étapes pour reproduire le bogue. Ne supposez pas ou ne sautez aucune étape de reproduction. Un bug qui est décrit étape par étape est facile à reproduire et à corriger.

#3) Soyez spécifique : N’écrivez pas un essai sur le problème.

Soyez spécifique et allez droit au but. Essayez de résumer le problème en un minimum de mots mais de manière efficace. Ne combinez pas plusieurs problèmes même s’ils semblent être similaires. Rédigez des rapports différents pour chaque problème.

Rapports de bogues efficaces

Les rapports de bogues sont un aspect important des tests logiciels. Un rapport de Bug efficace communique bien avec l’équipe de développement et évite toute confusion ou mauvaise communication.

Un bon rapport de Bug doit être clair et concis sans qu’aucun point clé ne manque. Tout manque de clarté entraîne des malentendus et ralentit également le processus de développement. La rédaction et le signalement des défauts sont l’un des domaines les plus importants mais négligés du cycle de vie des tests.

Une bonne rédaction est très importante pour déposer un bug. Le point le plus important qu’un testeur doit garder à l’esprit est de ne pas utiliser un ton autoritaire dans le rapport. Cela casse le moral et crée une relation de travail malsaine. Utilisez un ton suggestif.

Ne supposez pas que le développeur a fait une erreur et donc vous pouvez utiliser des mots durs. Avant de signaler, il est également important de vérifier si le même bogue a été signalé ou non.

Un bogue en double est un fardeau dans le cycle de test. Vérifiez toute la liste des bugs connus. Parfois, les développeurs peuvent avoir connu le problème et l’avoir ignoré pour une version ultérieure. Des outils comme Bugzilla qui recherche automatiquement les bogues en double peuvent également être utilisés. Cependant, il est préférable de rechercher manuellement tout bogue en double.

Les informations d’importation qu’un rapport de bogue doit communiquer sont « Comment ? » et « Où ? ». Le rapport doit répondre clairement à la façon dont le test a été effectué et où le défaut s’est produit exactement. Le lecteur doit facilement reproduire le bug et trouver où se trouve le bug.

N’oubliez pas que l’objectif de la rédaction du rapport de bug est de permettre au développeur de visualiser le problème. Il/elle doit clairement comprendre le défaut à partir du rapport de bug. N’oubliez pas de donner toutes les informations pertinentes que le développeur recherche.

En outre, gardez à l’esprit qu’un rapport de bug serait conservé pour une utilisation future et devrait être bien écrit avec les informations requises. Utilisez des phrases significatives et des mots simples pour décrire vos bugs. N’utilisez pas de déclarations confuses qui font perdre du temps à l’examinateur.

Reportez chaque bogue comme un problème distinct. En cas de problèmes multiples dans un seul rapport de bogue, vous ne pouvez pas le fermer à moins que tous les problèmes soient résolus.

Il est donc préférable de diviser les problèmes en bogues distincts. Cela garantit que chaque bogue peut être traité séparément. Un rapport de bogue bien écrit aide un développeur à reproduire le bogue sur son terminal. Cela l’aide également à diagnostiquer le problème.

Comment signaler un bogue?

Utilisez le modèle de rapport de bogue simple suivant :

C’est un format de rapport de bogue simple. Il peut varier en fonction de l’outil de rapport de bogue que vous utilisez. Si vous écrivez un rapport de bogue manuellement, alors certains champs doivent être mentionnés spécifiquement comme le numéro de bogue, qui doit être attribué manuellement.

Reporteur : votre nom et votre adresse e-mail.

Produit : Dans quel produit vous avez trouvé ce bogue.

Version : La version du produit si elle existe.

Composant : Ce sont les principaux sous-modules du produit.

Plateforme : Mentionnez la plateforme matérielle où vous avez trouvé ce bug. Les différentes plateformes comme ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.

Système d’exploitation : Mentionnez tous les systèmes d’exploitation où vous avez trouvé ce bogue. Les systèmes d’exploitation comme Windows, Linux, Unix, SunOS, Mac OS. Mentionnez également les différentes versions du système d’exploitation comme Windows NT, Windows 2000, Windows XP etc, le cas échéant.

Priorité : Quand un bogue doit-il être corrigé ? La priorité est généralement fixée de P1 à P5. P1 comme  » Corriger le bug avec la plus haute priorité  » et P5 comme  » Corriger quand le temps le permet « .

Sévérité : Ceci décrit l’impact du bogue.
Types de gravité :

• Bloqueur : Aucun autre travail de test ne peut être effectué.
• Critique : Crash de l’application, perte de données.
• Majeur : Perte majeure de fonction.
• Mineure : Perte mineure de fonction.
• Trivial : Quelques améliorations de l’interface utilisateur.
• Amélioration : Demande d’une nouvelle fonctionnalité ou d’une certaine amélioration de la fonctionnalité existante.

Status : Lorsque vous enregistrez le bogue dans n’importe quel système de suivi des bogues, alors par défaut le statut du bogue sera ‘Nouveau’.
Plus tard, le bogue passe par différentes étapes comme Fixé, Vérifié, Réouvert, Won’t Fix, etc.

=> Cliquez ici pour en savoir plus sur le cycle de vie détaillé des bogues.

Assigner à : Si vous savez quel développeur est responsable de ce module particulier dans lequel le bug s’est produit, alors vous pouvez spécifier l’adresse e-mail de ce développeur. Else gardez-le vide car cela assignera le bug au propriétaire du module sinon le Manager assignera le bug au développeur. Éventuellement, ajoutez l’adresse électronique du gestionnaire dans la liste CC.

URL : L’URL de la page sur laquelle le bug s’est produit.

Résumé : Un bref résumé du bug principalement en 60 mots ou moins. Assurez-vous que votre résumé reflète ce qu’est le problème et où il se trouve.

Description : Une description détaillée du bogue.

Utilisez les champs suivants pour le champ de description :

• Reproduire les étapes : Mentionnez clairement les étapes permettant de reproduire le bogue.
• Résultat attendu : Comment l’application devrait se comporter lors des étapes mentionnées ci-dessus.
• Résultat réel : Quel est le résultat réel de l’exécution des étapes ci-dessus, c’est-à-dire le comportement du bug.

Ce sont les étapes importantes du rapport de bug. Vous pouvez également ajouter le « type de rapport » comme un champ supplémentaire qui décrira le type de bug.

Les types de rapport comprennent :

1) Erreur de codage
2) Erreur de conception
3) Nouvelle suggestion
4) Problème de documentation
5) Problème de matériel

Caractéristiques importantes dans votre rapport de bug

Données ci-dessous sont les caractéristiques importantes dans le rapport de bug :

#1) Numéro/identification du bug

Un numéro de bug ou un numéro d’identification (comme swb001) facilite grandement le signalement et la référence à un bug. Le développeur peut facilement vérifier si un bug particulier a été corrigé ou non. Cela rend l’ensemble du processus de test et de re-test plus fluide et plus facile.

#2) Titre du bug

Un titre de bug est lu plus souvent que toute autre partie du rapport de bug. Il doit tout dire sur ce qui vient dans le bug.

Le titre du bug doit être suffisamment suggestif pour que le lecteur puisse le comprendre. Un titre de bug clair le rend facile à comprendre et le lecteur peut savoir si le bug a été signalé plus tôt ou a été corrigé.

#3) Priorité

Selon la gravité du bug, une priorité peut lui être fixée. Un bug peut être un bloqueur, un critique, un majeur, un mineur, un trivial ou une suggestion. Une priorité de bug de P1 à P5 peut être donnée afin que les plus importants soient vus en premier.

#4) Plateforme/Environnement

La configuration du système d’exploitation et du navigateur est nécessaire pour un rapport de bug clair. C’est le meilleur moyen de communiquer comment le bug peut être reproduit.

Sans la plateforme ou l’environnement exact, l’application peut se comporter différemment et le bug chez le testeur peut ne pas se reproduire chez le développeur. Il est donc préférable de mentionner clairement l’environnement dans lequel le bug a été détecté.

#5) Description

La description du bug aide le développeur à comprendre le bug. Elle décrit le problème rencontré. La mauvaise description créera de la confusion et fera perdre du temps aux développeurs ainsi qu’aux testeurs.

Il est nécessaire de communiquer clairement sur l’effet de la description. Il est toujours utile d’utiliser des phrases complètes. C’est une bonne pratique de décrire chaque problème séparément au lieu de les émietter tous ensemble. N’utilisez pas de termes comme « je pense » ou « je crois ».

#6) Étapes de reproduction

Un bon rapport de Bug doit mentionner clairement les étapes de reproduction. Les étapes doivent inclure les actions qui provoquent le bug. Ne faites pas de déclarations génériques. Soyez précis dans les étapes à suivre.

Un bon exemple de procédure bien écrite est donné ci-dessous

Étapes:

• Sélectionnez le produit Abc01.
• Cliquez sur Ajouter au panier.
• Cliquez sur Supprimer pour retirer le produit du panier.

#7) Résultat attendu et réel

Une description de bogue est incomplète sans les résultats attendus et réels. Il est nécessaire d’exposer quel est le résultat du test et ce à quoi l’utilisateur doit s’attendre. Le lecteur doit savoir quel est le résultat correct du test. Clairement, mentionnez ce qui s’est passé pendant le test et quel a été le résultat.

#8) Capture d’écran

Une image vaut mille mots. Prenez une capture d’écran de l’instance d’échec avec un sous-titre approprié pour mettre en évidence le défaut. Mettez en évidence les messages d’erreur inattendus avec une couleur rouge clair. Cela attire l’attention sur la zone requise.

Certains conseils supplémentaires pour écrire un bon rapport de bogue

Donnés ci-dessous sont quelques conseils supplémentaires pour écrire un bon rapport de bogue:

#1) Signaler le problème immédiatement

Si vous trouvez un bogue pendant le test, alors ne pas attendre pour écrire un rapport de bogue détaillé plus tard. Au lieu de cela, écrivez le rapport de bug immédiatement. Cela garantira un rapport de bogue bon et reproductible. Si vous décidez d’écrire le rapport de Bug plus tard alors il y a de grandes chances de manquer les étapes importantes dans votre rapport.

#2) Reproduisez le bug trois fois avant d’écrire un rapport de Bug

Votre bug doit être reproductible. Assurez-vous que vos étapes sont suffisamment robustes pour reproduire le bug sans aucune ambiguïté. Si votre bug n’est pas reproductible à chaque fois, vous pouvez toujours déposer un bug en mentionnant la nature périodique du bug.

#3) Testez la même occurrence de bug sur d’autres modules similaires

Parfois, le développeur utilise le même code pour différents modules similaires. Il y a donc plus de chances que le bug dans un module se produise également dans d’autres modules similaires. Vous pouvez même essayer de trouver la version plus sévère du bug que vous avez trouvé.

#4) Rédiger un bon résumé du bug

Le résumé du bug aidera les développeurs à analyser rapidement la nature du bug. Un rapport de mauvaise qualité augmentera inutilement le temps de développement et de test. Communiquez bien avec votre résumé de rapport de bug. Gardez à l’esprit que le résumé du bug est utilisé comme référence pour rechercher le bug dans l’inventaire des bugs.

#5) Lisez le rapport de bogue avant d’appuyer sur le bouton Soumettre

Lisez toutes les phrases, formulations et étapes qui sont utilisées dans le rapport de bogue. Voyez si une phrase crée une ambiguïté qui peut conduire à une mauvaise interprétation. Les mots ou les phrases trompeuses doivent être évités afin d’avoir un rapport de bug clair.

#6) N’utilisez pas de langage abusif

C’est bien que vous ayez fait du bon travail et trouvé un bug mais n’utilisez pas ce crédit pour critiquer le développeur ou pour attaquer une personne.

Conclusion

Il ne fait aucun doute que votre rapport de bogue doit être un document de haute qualité.

Concentrez-vous sur la rédaction de bons rapports de bogue et consacrez du temps à cette tâche car c’est le principal point de communication entre le testeur, le développeur et le manager. Les gestionnaires devraient faire prendre conscience à leur équipe que la rédaction d’un bon rapport de bogue est la principale responsabilité de tout testeur.

>