Que faut-il inclure dans un rapport de bogue?



Comment rédiger un bon rapport de bogue

La rédaction d'un bon rapport de défaut ou de bogue permet d'identifier et de résoudre rapidement les problèmes. Dans cet article, nous listons les éléments communs qui sont normalement inclus dans un rapport de bogue.

Dans aucun ordre particulier:

Identifiant de défaut, ID

L'identifiant est très important pour pouvoir faire référence au défaut dans les rapports. Si un outil de rapport de défauts est utilisé pour consigner les défauts, l'ID est normalement un numéro unique généré par le programme qui s'incrémente par journal de défauts.


Résumé

Le résumé est une description globale de haut niveau du défaut et de la défaillance observée. Ce bref résumé devrait être un point culminant du défaut car c'est ce que les développeurs ou les réviseurs voient en premier dans le rapport de bogue.

La description

La nature du défaut doit être clairement écrite. Si un développeur examinant le défaut ne peut pas comprendre et ne peut pas suivre les détails du défaut, le rapport sera très probablement renvoyé au testeur demandant plus d'explications et plus de détails, ce qui retardera la résolution du problème.


La description doit expliquer exactement les étapes à suivre pour reproduire le défaut, ainsi que les résultats attendus et le résultat de l'étape de test. Le rapport doit indiquer à quelle étape l'échec a été observé.

Gravité

La gravité du défaut montre à quel point le défaut est grave en termes de dommages aux autres systèmes, aux entreprises, à l'environnement et à la vie des personnes, en fonction de la nature du système d'application. Les niveaux de gravité sont normalement classés et classés en 4 ou 5 niveaux, selon la définition de l'organisation.

  • S1 - Critique: Cela signifie que le défaut est un bouchon d'exposition avec des dommages potentiels élevés et n'a pas de solution de contournement pour éviter le défaut. Par exemple, l'application ne se lance pas du tout et provoque l'arrêt du système d'exploitation. Cela nécessite une attention et une action immédiates et une correction.
  • S2 - Sérieux: Cela signifie que certaines fonctionnalités principales des applications sont manquantes ou ne fonctionnent pas et qu'il n'y a pas de solution de contournement. Par exemple, une application de visualisation d'images ne peut pas lire certains formats d'image courants.
  • S3 - Normal: Cela signifie que certaines fonctionnalités majeures ne fonctionnent pas, mais qu'une solution de contournement existe pour être utilisée comme solution temporaire.
  • S4 - Cosmétique / Amélioration: Cela signifie que l'échec entraîne des inconvénients et des ennuis. Par exemple, il y a un message contextuel toutes les 15 minutes, ou vous devez toujours cliquer deux fois sur un bouton de l'interface graphique pour effectuer l'action.
  • S5 - Suggestion: Ce n'est normalement pas un défaut et une suggestion pour améliorer une fonctionnalité. Cela peut être l'interface graphique ou les préférences d'affichage.

Priorité

Une fois la gravité déterminée, il faut ensuite voir comment hiérarchiser la résolution. La priorité détermine la rapidité avec laquelle le défaut doit être corrigé. La priorité concerne normalement l'importance commerciale telle que l'impact sur le projet et le succès probable du produit sur le marché. Tout comme la gravité, la priorité est également classée en 4 ou 5 niveaux.

  • P1 - Urgent: Signifie extrêmement urgent et nécessite une résolution immédiate
  • P2 - Élevé: Exigence de résolution pour la prochaine version externe
  • P3 - Moyen: Résolution requise pour le premier déploiement (plutôt que pour tous les déploiements)
  • P4 - Faible: Résolution souhaitée pour le premier déploiement ou les futures versions ultérieures

En savoir plus sur la gravité par rapport à la priorité


Il est important de noter qu'un défaut qui a une gravité élevée a également une priorité élevée, c'est-à-dire qu'un défaut grave nécessitera une priorité élevée pour résoudre le problème le plus rapidement possible. Il ne peut jamais y avoir de défaut de gravité élevée et de faible priorité. Cependant, un défaut peut avoir une gravité faible mais avoir une priorité élevée.

Par exemple, le nom d'une société est mal orthographié sur l'écran de démarrage lors du lancement de l'application. Cela ne cause pas de dommages graves à l’environnement ou à la vie des gens, mais peut avoir des effets négatifs sur la réputation de l’entreprise et peut nuire aux bénéfices de l’entreprise.

Date et l'heure

La date et l'heure auxquelles le défaut est survenu ou signalé sont également essentielles. Ceci est normalement utile lorsque vous souhaitez rechercher des défauts qui ont été identifiés pour une version particulière d'un logiciel ou à partir du début de la phase de test.

Version et construction du logiciel testé

Ceci est également très important. Dans la plupart des cas, il existe de nombreuses versions de logiciels; chaque version comporte de nombreux correctifs et davantage de fonctionnalités et d'améliorations par rapport aux versions précédentes. Par conséquent, il est essentiel de noter quelle version du logiciel a présenté la panne que nous signalons. Nous pouvons toujours nous référer à cette version du logiciel pour reproduire la panne.


Rapporté par

Encore une fois, c'est important, car si nous pouvons avoir besoin de nous référer à la personne qui a soulevé le défaut, nous devons savoir qui contacter.

Exigence connexe

Essentiellement, toutes les fonctionnalités d'une application logicielle peuvent être attribuées aux exigences respectives. Ainsi, lorsqu'une défaillance est observée, nous pouvons voir quelles exigences ont été impactées.

Cela peut aider à réduire les rapports de défauts en double dans la mesure où si nous pouvons identifier l'exigence source, si un autre défaut est enregistré avec le même numéro d'exigence, nous n'aurons peut-être pas besoin de le signaler à nouveau, si les défauts sont de nature similaire.

Pièces jointes / preuves

Toute preuve de la défaillance doit être capturée et soumise avec le rapport de défaut. Ceci est une explication visuelle de la description du défaut et aide le réviseur, le développeur à mieux comprendre le défaut.


Conclusion

Dans cet article, nous avons appris quelles informations nous devrions généralement inclure dans un rapport de bogue. La création d'un bon rapport de bogue accélère l'analyse des causes profondes et la correction du bogue.