L'anatomie d'un bon rapport de bogue
Publié: 2020-12-16Depuis près d'un siècle et demi, les ingénieurs qualifient de «bugs» les petits défauts des machines. 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 bogue informatique a été documenté le 9 septembre 1947 par Grace Murray Hopper. Elle a signalé qu'un papillon de nuit était coincé entre les contacts de relais de l'ordinateur Harvard Mark II. Le bogue a été enregistré dans le journal de bord de l'ordinateur.
Pour en savoir plus sur le premier rapport de bogue, cliquez ici.
Depuis lors, les rapports de bogues constituent une partie importante de l'ensemble du processus d'AQ. 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?
Dans le développement de sites Web, un rapport de bogue est le principal outil utilisé pour indiquer qu'un certain morceau de code ne fonctionne pas comme prévu. Il existe de nombreux exemples différents de «bogues», mais pour n'en nommer que quelques-uns:
- Un site Web se bloque en raison d'une utilisation excessive de ressources système
- Les images semblent étranges sur certains navigateurs ou appareils
- Une boutique en ligne affiche des prix incorrects pour certains produits
- Une fonctionnalité ne fonctionne pas conformément aux exigences du client
Le but principal d'un rapport de bogue est de permettre à l'équipe de développement de reproduire le problème qui a été signalé par l'équipe QA. Il est important de disposer de toutes les informations nécessaires pour faciliter le processus de débogage et de correction.
Les rapports de bogues sont utilisés non seulement pour signaler des problèmes, mais également pour suggérer de nouvelles fonctionnalités et améliorations . En tant que tel, la plupart des directives sur ce qu'un bon rapport de bogue devrait inclure s'appliqueraient également aux suggestions.
Article connexe: Comment développer un plan d'assurance qualité pour votre site Web WordPress
Que doit inclure un rapport de bogue?
Un bon rapport de bogue doit inclure des informations précises sur le problème qui s'est produit. Pour que cela se produise, les éléments suivants, comme dans le modèle que nous utilisons ici chez DevriX, doivent être présents. Chez Devrix, le modèle de rapport de bogue est basé sur ces éléments. Il a été prouvé qu'ils fournissent suffisamment d'informations sur les problèmes rencontrés.
- Titre - Cela devrait servir de bref résumé de la nature du problème. Il est important que le titre précise la nature du problème. C'est la première chose qu'un développeur voit.
- Statut - Ceci est un indicateur de l'état du rapport de bogue. Il peut y avoir différents types de statues., Selon le logiciel de gestion utilisé (comme Jira, Asana, Trello, Mantis, etc.). Quelques exemples:
- À attribuer - Lorsqu'il reste à déterminer qui examinera les problèmes dans le rapport.
- En cours - Lorsqu'un développeur travaille sur la résolution du bogue signalé. Cet état est également utilisé lorsqu'une mise à jour est en cours de test.
- Terminé - Un signe que le bogue signalé a été résolu.
- Priorité - Cela indique l'urgence d'un bogue signalé, par rapport à d'autres tâches et problèmes. La priorité d'un bogue est liée à la gravité d'un bogue car elle mesure l'impact sur le système testé. Les priorités les plus courantes sont:
- Critique - Utilisé pour les problèmes où toutes les autres activités doivent cesser et tous les efforts sont concentrés pour résoudre la situation. Cela est dû au fait que ces problèmes ont un impact majeur sur le projet pour lequel ils sont signalés et pourraient entraîner des pertes pour l'entreprise.
- Élevé - Utilisé pour les problèmes qui devraient être résolus le plus tôt possible. Ils n'ont pas un impact aussi important, mais s'il n'y a pas de problèmes critiques, ils doivent être résolus dès que possible.
- Moyen - Utilisé pour les problèmes qui n'ont pas d'impact majeur sur les fonctionnalités de base. Ce serait bien de les résoudre. Ces problèmes doivent être résolus après ceux qui ont la priorité la plus élevée.
- Faible - Utilisé lorsque le bogue signalé est mineur et n'a pas d'effet sur la fonctionnalité principale. Cela peut être une erreur grammaticale dans un article de blog ou la mauvaise couleur pour un bouton.
- Gravité - Utilisé pour afficher le niveau d'impact du bogue signalé sur le système testé. La classification la plus courante pour la gravité d'un bogue est:
- Critique - Une fonctionnalité de base ne fonctionne pas ou l'ensemble du logiciel ne fonctionne pas.
- Majeur - Une ou plusieurs fonctionnalités de base sont affectées par le bogue. Pour cette raison, le logiciel testé ne produit pas les résultats souhaités. Contrairement aux bogues de gravité critique, certaines fonctionnalités fonctionneront comme prévu.
- Modéré - Il n'y a aucun impact sur les fonctionnalités de base du logiciel testé. Un ou plusieurs composants sont affectés, ce qui entraîne un comportement incohérent.
- Mineur - L'impact sur le logiciel testé est mineur.
- Trivial - Les bogues de cette gravité n'affectent pas la fonctionnalité du logiciel. Il peut s'agir de défauts visuels mineurs, de traductions manquantes, d'un message de confirmation ne fonctionnant pas, etc.
- Détails du bogue - Les détails contiennent des informations importantes sur l'emplacement du problème signalé. Les informations suivantes doivent être incluses (bien que différentes organisations puissent exiger des détails (bogues) différents):
- Le navigateur où le bogue a été rencontré (il est préférable d'inclure également la version)
- Le système d'exploitation - Cela pourrait être un problème, observé uniquement sous Windows. Cela inclut également les systèmes d'exploitation mobiles comme Android, iOS et PadOS
- La branche - Ceci est pour les mises à jour non publiées (nouvelles fonctionnalités ou mises à jour qui corrigent d'autres bogues signalés). La branche ne contient que des commits spécifiques, pertinents pour une fonctionnalité. Ceci est fait pour qu'un changement n'interfère pas avec le travail d'autres personnes sur le même projet
- Version - Si le logiciel testé est une application de bureau ou mobile. il est conseillé d'inclure la version où le bogue a été signalé.
- Description du bogue - Le spécialiste QA doit fournir une explication précise du problème observé, ainsi que les étapes nécessaires pour reproduire le problème. Le spécialiste doit également décrire le résultat attendu. Tous ces éléments sont importants pour aider l'équipe de développement à comprendre quel est le problème, quelles actions doivent être effectuées pour le reproduire et quel devrait être le comportement correct.
- Pièces jointes / captures d'écran - Une pièce jointe / capture d'écran permet au spécialiste de voir où et souvent le problème. Il peut également fournir au spécialiste QA les étapes qui ont été effectuées pour déclencher le problème.
- Commentaires - La section des commentaires n'est généralement pas utilisée lorsqu'un nouveau rapport de bogue est créé, mais il est important de partager quelques mots sur ce qui doit être inclus dans les commentaires du développeur (et les commentaires suivants) lorsqu'un correctif de bogue est soumis au Équipe d'assurance qualité pour les tests. Les développeurs doivent inclure les éléments suivants:
- Lien vers le commit qui contient la mise à jour.
- Expliquez ce que fait la mise à jour.
- S'il y a des étapes de configuration à effectuer, il est important de les expliquer.
- Joignez des captures d'écran / screencasts montrant la mise à jour en action.
- Incluez toutes les remarques que le spécialiste QA doit prendre en compte lors du test de la mise à jour.
Ressources associées : Le travail d'assurance qualité est une partie essentielle du travail sur chaque site Web. C'est pourquoi passer par la phase longue et détaillée des tests, de la correction des bogues et des régressions et de la stabilisation de la plate-forme pour le lancement est lié au coût du site Web.

Rédaction de tâches pour les suggestions et les nouvelles fonctionnalités
Lors de l'exécution des tests de contrôle qualité, les testeurs expérimentés proposent généralement des idées d'amélioration du projet. De même, les chefs de projet et les chefs de projet doivent recevoir les demandes des clients (pour les fonctionnalités, les correctifs, les améliorations) qui doivent être partagées avec l'équipe de développement.
Contrairement aux rapports de bogues, le but des tâches Suggestions et Nouvelles fonctionnalités est d'expliquer les demandes des clients ou les idées d'amélioration qui ont le potentiel d'améliorer le projet (comme la mise en œuvre d'une mise à jour des performances, l'ajout d'une fonctionnalité qui permettrait une meilleure interaction avec les utilisateurs. , etc).
Dans les deux cas, il est important de fournir une description claire de la fonctionnalité à implémenter:
- Nouvelles fonctionnalités, requises par le client - Il est important que le propriétaire du projet / chef de projet comprenne ce dont le client a besoin, examine toutes les maquettes fournies et discute de tout détail supplémentaire. Une fois que ce que veut le client est clair, il est plus facile d'expliquer à l'équipe de développement ce qu'il doit faire.
- Suggestions - Il est important d'avoir une vision claire du projet dans son ensemble et de la manière dont la fonctionnalité suggérée va l'améliorer. De cette façon, il sera plus facile d'expliquer l'idée et les avantages qu'elle apporterait.
Rapports de bogues bons et mauvais: exemples
Avertissement : Les exemples suivants sont tirés d'un projet de cours d'assurance qualité auquel l'auteur a participé. Le but est d'analyser les erreurs qui ont été commises dans les rapports et comment les éviter.
Exemple 1 :
Voici un exemple de rapport de bogue bien rédigé. Il comprend tous les attributs décrits ci-dessus.
Cependant, il y a un problème avec celui-ci: 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 rédigé. 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 attendu n'explique pas réellement quel est le comportement correct.
Des rapports de bogues mal rédigés obligent l'équipe de développement à passer un temps inutile à déterminer quel est le problème et où se trouve le problème signalé. L'équipe doit souvent demander au spécialiste QA qui a signalé le bogue de clarifier les détails manquants ...
Exemple 3 :
Ceci est un bon exemple de rapport de bogue correctement rédigé. Cela donne à l'équipe de développement une idée claire de l'emplacement du 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é assignées sont incorrectes. Si le spécialiste QA a 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 permettre à l'équipe de développement de comprendre 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 sur laquelle 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 ce que le comportement attendu devrait être 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 la tâche appropriées.
- Joignez tous les fichiers pertinents - captures d'écran, screencasts, journaux, etc.
- Incluez toute information supplémentaire qui pourrait aider l'équipe de développement à résoudre le problème.