Comment rédiger un rapport de bug avec des exemples

Par : Lucas Bennett Lucas Bennett
Hours Le kit de préparation mis à jour

Qu'est-ce qu'un rapport de bug ? Pourquoi avez-vous besoin d'un bon rapport de bug ?

Bug Report est un document important dans STLC qui offre divers avantages à l'équipe de test. Il garde une trace de tous les défauts, bogues multiples, erreurs et autres écarts trouvés lors des tests logiciels et les signale.

Le but de cette documentation post-test est de fournir des informations à l'équipe de professionnels concernée sur le niveau de bugs rencontrés au cours du processus de test.

Votre ingénieur développement logiciel peut être informé de tous les défauts et problèmes présents dans le logiciel à l’aide de ce type de rapport. Il vous permet également de déterminer ce qui ne va pas avec un bug, afin que vous puissiez utiliser la meilleure méthode pour le corriger. Il vous aide également à économiser du temps et de l'argent en vous aidant à détecter les bugs et les problèmes.

Pourquoi devriez-vous vous soucier de bonnes explications de bugs ?

Bonnes explications de bugs

Voici le point que vous devez prendre en compte pour rédiger un bon rapport détaillé de bogues logiciels :

  • Il sert de guide pour éviter le même bug dans les versions futures.
  • Gagnez du temps pour la communication (e-mails, appels).
  • Less travaillez pour les développeurs (ils feront exactement ce que vous voulez).
  • Vous aurez moins de goulots d'étranglement dans le projet ; les bugs seront corrigés de manière plus rapide et plus efficace.

Comment rédiger un rapport de bug (modèle de rapport de bug)

Il n'existe pas de modèle de rapport de bug précis, car cela dépend de votre système de suivi des bugs. Votre modèle peut être différent.

Cependant, les champs courants suivants sont toujours nécessaires lorsque vous souhaitez rédiger un rapport de bug :

  • ID de bogue/titre.
  • Gravité et priorité.
  • Description
  • Environnement
  • Étapes à reproduire.
  • Résultat attendu.
  • Résultat actuel.
  • Pièces jointes (captures d'écran, vidéos, texte)

Examinons tous ces composants de correction de bugs un par un :

1) Titre/ID de bogue :

Chaque bug doit recevoir un numéro d’identification unique. Les outils de rapport de bogues doivent comporter des numéros uniques pour les bogues nouvellement signalés afin que nous puissions facilement identifier le bogue.

Exemples :

❌ Mauvais : "Je ne vois pas le produit quand je le revois, mais ce n'est pas le cas."

  • vague
  • Aggressive
  • Trop verbeux

demande qu'une solution soit mise en œuvre.

✅ Bon : « PANIER – Nouveaux articles ajoutés au panier qui n'apparaissent pas ».

  • Ce type de titre localise instantanément le problème (CART)
  • Il se concentre sur le problème technique réel.

2) Gravité du bug :

La gravité des bogues est un facteur très important dans le rapport de bogues. Il décrit l'effet du défaut sur les performances de l'application.

  • Bloqueurs : Cette erreur provoque l'échec de l'application.
  • Major: Une erreur critique indique un changement majeur dans la logique métier.
  • Mineure: Un problème qui n'affecte pas les fonctionnalités de l'application mais affecte les résultats attendus.
  • Banal: Cela n'affecte pas la fonctionnalité ou le fonctionnement de l'application. Il pourrait s'agir d'une erreur typographique.

3) Priorité des bogues :

Voici la gradation générale pour décider de la priorité des bogues :

  • Haut: Il couvre tout ce qui affecte le flux ou bloque l'utilisation de l'application.
  • Moyen: Cela affecte négativement l’expérience utilisateur.
  • Mineure: Toutes les autres erreurs telles que (fautes de frappe, icônes manquantes, problèmes de mise en page, etc.).

4) Environnement :

Un Bug peut apparaître dans un environnement spécifique et pas dans d’autres. Par exemple, il arrive parfois qu'un bug apparaisse lors de l'exécution du site Web sur Firefox, ou un dysfonctionnement de l'application uniquement lors de son exécution sur un Android appareil et fonctionne bien sur iPhone.

Ces rapports de bogues ne peuvent être identifiés qu’avec des tests multi-navigateurs ou multi-appareils. Ainsi, lors du signalement du bug, les QA doivent être en mesure de spécifier si le bug doit être observé dans un ou plusieurs environnements spécifiques.

5) Résumé :

Cependant, ajouter uniquement le titre dans le rapport de bug ne sert à rien. Ainsi, si votre titre ne suffit pas, vous pouvez ajouter un bref résumé du rapport.

Votre résumé en aussi peu de mots que possible, indiquant quand et comment le bug s'est produit. Votre titre et la description du bug doivent également être utilisés dans les recherches, vous devez donc vous assurer que vous avez couvert des mots-clés importants.

Exemples:

  • Bad: "J'essayais d'ajouter des éléments au test, et rien ne s'est affiché lorsque j'ai fait cela ou cliqué sur le bouton."
  • Bon: "Lorsque j'ai essayé d'ajouter [PRODUIT] au panier, rien ne s'est produit lorsque j'ai cliqué sur le bouton "Ajouter" sur la page Web de présentation du produit spécifique."

6) Étapes à reproduire :

Lors du signalement d’un bug, il est important de préciser les étapes pour le reproduire. Vous devez également inclure les actions susceptibles de provoquer le bug. Ici, ne faites aucune déclaration générique.

Soyez précis sur les étapes à suivre :

Voici un exemple de procédure bien écrite :

Étape:

  1. Sélectionnez le produit X1.
  2. Cliquez sur Ajouter au panier.
  3. Cliquez sur Supprimer pour supprimer le produit du panier.

7) Résultat attendu :

Dans les rapports de bogues, il est important de décrire le résultat attendu en fonction de la tâche technique, de la conception des résultats du scénario de test ou selon l'opinion du testeur. Tout cela aide les développeurs à se concentrer sur la recherche rapide des informations nécessaires.

Par exemple :

Les champs obligatoires doivent être surlignés en rouge après avoir cliqué sur le bouton « Soumettre ».

8) Résultat réel :

Comme son nom l'indique, ce champ décrit l'effet réel du bug. Il est très important de rédiger une description claire du résultat réel.

Par exemple :

Les champs obligatoires sont surlignés en vert après avoir cliqué sur le bouton « Soumettre ».

9) Pièces jointes (captures d'écran et vidéos) :

Dans les rapports de bogues, il est recommandé de joindre des fichiers aux rapports de bogues, ce qui facilite la perception des informations lorsque vous devez les afficher visuellement :

Par exemple :

  • Capture d'écran: Les captures d'écran peuvent facilement révéler des erreurs dans le programme ; (ce qui est pratique lorsque le bug est mis en évidence avec une annotation spécifique, un cercle ou une image de flèche).
  • Vidéo: Parfois, il est difficile de décrire le bug avec des mots, il est donc préférable de créer une vidéo afin que le développeur puisse rectifier le défaut du programme).

10) Version concernée :

Il s'agit de la version du logiciel concernée dans laquelle le bug est signalé.

11) Version corrigée :

Il s'agit de la version du logiciel dans laquelle le bug est résolu. Ainsi, lorsque le QA qui a signalé le bug vérifie s'il est corrigé, il utilise la bonne version du logiciel.

12) Target Version:

La version cible sur laquelle un bug doit être ciblé pour être corrigé. Ainsi, lorsque l’équipe de développement travaille à la correction d’un bug, elle cible principalement une version particulière de l’application.

13) Date de clôture :

C'est la date à laquelle le bug est résolu par l'équipe de test du logiciel. La résolution d'un bogue est une partie vitale et intégrale des tests logiciels.

14) Statut :

Lorsqu'un nouveau bug est créé, son statut doit être ouvert. Après cela, il passe par des étapes telles que En cours, Corrigé, En cours d'exécution, Réouverture, etc.

ARTICLES LIÉS

Conseils pour la rédaction d'un rapport de bug

Voici quelques conseils importants dont vous devez vous souvenir lors de la rédaction d’un rapport de bug efficace :

  • Soyez précis lors de la création de rapports de bogues. Assurez-vous de ne pas inclure de faits inutiles ou non pertinents.
  • Vous devez signaler le bug immédiatement dès qu'il est détecté.
  • Préparez le rapport en détail pour permettre au développeur d'utiliser les faits et les informations pour déboguer le problème.
  • Vous devez tester la même occurrence de bogue sur d'autres modules similaires pour validation.
  • RevConsultez le rapport de bug au moins une fois avant de le soumettre.
  • Vous devez vous assurer que le rapport de bug contient la description d'une seule erreur.
  • Enfin, n’hésitez pas à demander de l’aide au chef de projet si vous n’êtes pas clair sur quelque chose.

Outils de rapport de bogues

Le processus de rapport de bogues, effectué manuellement, est désormais effectué avec divers outils de rapport de bogues disponibles sur le marché.

Vous pouvez consulter notre examen détaillé du meilleur outil de rapport de bogues.

Problème courant et solution lors de la rédaction d'un rapport de bug :

Voici quelques problèmes courants et leurs solutions lors de la rédaction d'un rapport de bug :

Exemple de rapport de bug Problème
En multipliant 2 par 3, la réponse sera positive. Signalez le modèle, pas un exemple.
La liste sera classée par ordre alphabétique lors de l'ajout d'un nouvel élément pour éviter cela. Ne décrivez pas seulement ce qui ne va pas
Par exemple :
Pour cela, vous devrez ouvrir votre navigateur et saisir l'URL du site. Vous trouverez le premier champ, « nom d'utilisateur », mal orthographié.		 Allez toujours droit au but (ne racontez jamais l’histoire !).
Le nom du client dans le rapport est mal orthographié. Priorité : élevée, gravité : élevée Ne mélangez jamais priorité et gravité.
La formule de calcul de la taxe est INCORRECT !!?? N'utilise pas de majuscules, de lettres rouges, de cercles rouges, de '!',
Je ne pense pas que le design de la page d'accueil Ul soit bon. N'utilisez pas votre jugement.
Exemple de description peu claire : à propos de notre discussion d'aujourd'hui, veuillez effectuer l'action requise pour cette page. Rendez votre description compréhensible pour tout le monde.
L'arrière-plan de la page doit être bleu, orange ou vert, ou vous pouvez le rendre noir ou blanc.

Ce n’est pas une bonne chose car ce qui est attendu de l’équipe de développement et de conception Web n’est pas clair.

 Réduire les options
La formule de calcul des impôts ne fonctionne parfois pas comme prévu. La règle d'or : n'utilisez pas le mot « Parfois ».

Exemple de rapport de bug

Voici un petit exemple de rapport de bug :

[MON COMPTE] Le soulignement s'affiche lorsque vous passez la souris sur le bouton Mettre à jour.

Description: Nous devons supprimer le soulignement lorsque vous passez la souris sur le bouton Mettre à jour dans la section Mon compte.

Lien : http://test.com/mv-account/

Navigateur/OS : Chrome 25. OSX Yosemite 10.10.2

Étapes à suivre pour reproduire:

1. Allez sur www.test.com

2. Connectez-vous via les identifiants de connexion

3. Accédez à Mon compte

4. Passez la souris sur le bouton Mettre à jour

Résultat actuel: il y a un soulignement.

Résultat attendu: pas de soulignement.

Données de connexion: test@test.com / mysecretpass12

Doit éviter les erreurs dans la rédaction du rapport de bug

Voici quelques erreurs importantes que vous devez éviter lors de la rédaction d’un rapport de bug :

  • N'écrivez pas sur votre insatisfaction et n'incluez jamais vos sentiments personnels.
  • Cela agace les gens qui veulent se concentrer sur la tâche lorsque vous surchargez votre message avec de nombreuses émoticônes.
  • Ne surchargez jamais votre message de points d'exclamation ; cela n'accélère pas le travail.
  • Personne ne veut se sentir offensé. Cela détruit la motivation et ralentit la prise de conscience du problème.

Tu pourrais aimer: