L'anatomie d'un bon rapport de bug

Depuis près d'un siècle et demi, les ingénieurs qualifient les petits défauts des machines de «bugs». De nos jours, les «bogues» sont utilisés pour les problèmes matériels et logiciels des ordinateurs et des gadgets. Les bogues informatiques existent depuis pas mal de temps et avec eux sont également venus les rapports de bogues.

Le tout premier rapport de bug informatique a été documenté le 9 septembre 1947 par Grace Murray Hopper. Elle a signalé qu'un papillon de nuit réel était coincé entre les contacts de relais dans l'ordinateur Harvard Mark II. Le bug a été enregistré dans le journal de l'ordinateur.

Pour en savoir plus sur le premier rapport de bogue, cliquez ici.

Depuis lors, les rapports de bogues ont été une partie importante de l'ensemble du processus d'assurance qualité. Ils restent le principal outil de signalement des défauts dans les codes de programmation.

Cet article couvre ce qui doit être inclus dans un bon rapport de bogue. Il y aura également quelques exemples de bons et de mauvais rapports de bogues, y compris une brève analyse de chacun.

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

Voici un exemple de rapport de bogue bien écrit. Il comprend tous les attributs décrits ci-dessus.

Cependant, il présente un problème: son titre ne donne pas une idée précise du problème signalé. L'image du produit manquante peut se trouver n'importe où sur la boutique en ligne testée.

Un meilleur titre est «Images de produits manquantes dans la section« Les personnes qui ont acheté cet article ont également acheté »». De cette façon, l'équipe de développement aurait une idée de l'objet du rapport à partir du titre lui-même.

Exemple 2:

Ceci est un exemple de rapport de bogue globalement mal écrit. Les principaux problèmes avec cet exemple sont:

• Le titre ne précise pas où se trouve exactement le prix manquant
• La description ne précise pas où exactement le problème a été observé.
• Le résultat escompté n’explique pas réellement le comportement correct.

Des rapports de bogue mal rédigés obligent l'équipe de développement à consacrer du temps inutile à déterminer le problème et à localiser le problème signalé. L'équipe doit souvent recourir à demander au spécialiste QA qui a signalé le bug de clarifier les détails manquants…

Exemple 3:

Ceci est un bon exemple de rapport de bogue correctement écrit. Il donne à l'équipe de développement une idée claire de l'endroit où se trouve le problème et de la manière dont il peut être reproduit.

Un léger problème avec ce rapport est que le problème signalé n'arrête pas réellement le processus de test, ce qui signifie que la gravité et la priorité attribuées sont incorrectes. Si le spécialiste de l'assurance qualité avait mieux étudié le problème, il aurait remarqué qu'il existe une solution de contournement.

Cette solution de contournement aurait permis de terminer le processus d'enregistrement de compte. Il est très important d'étudier un problème avant qu'il ne soit signalé afin qu'aucun détail important ne soit exclu et que la gravité et la priorité correctes puissent être attribuées.

En conclusion

Un rapport de bogue bien rédigé par les QA est essentiel pour que l'équipe de développement comprenne quel est le problème et comment il est censé être résolu. Pour que cela se produise, rappelez-vous toujours ce qui suit:

• Le titre du rapport de bogue doit résumer le problème signalé.
• Fournissez des détails précis – la plate-forme où le problème est observé, le navigateur (pour les applications Web), la branche où le problème est observé.
• Fournissez une description claire du problème signalé.
• Assurez-vous que les étapes de reproduction sont exactes.
• Notez le comportement attendu par opposition à ce qui est réellement observé au moment de la création du rapport.
• N'oubliez pas d'attribuer la priorité et la gravité de tâche appropriées.
• Joignez tous les fichiers pertinents – captures d'écran, captures d'écran, journaux, etc.
• Incluez toute information supplémentaire qui pourrait aider l'équipe de développement à résoudre le problème.

Martin Mitrev

Assurance qualité chez Auteur
Martin est à l'avant-garde de la décomposition du code et des vulnérabilités des projets depuis plus de 5 ans maintenant. Il aime rendre les développeurs fous parce qu'il vise la perfection et aime les détails. Il est également un joueur passionné, un passionné de musique et un père de chat fier.