Comment rédiger un rapport de bug avec des exemples
Lucas Bennett
⚡ Résumé intelligent
La rédaction de rapports de bogues est une compétence essentielle en matière de tests qui permet de documenter clairement les défauts, d'accélérer les corrections et d'améliorer la qualité des logiciels en fournissant aux développeurs des étapes reproductibles, la gravité, la priorité, les détails de l'environnement et les pièces jointes nécessaires tout au long du cycle de vie des tests logiciels.
Qu'est-ce qu'un rapport de bug ? Pourquoi avez-vous besoin d'un bon rapport de bug ?
Le rapport de bogue est un document important du cycle de vie des tests logiciels (STLC) qui offre de nombreux avantages à l'équipe de test. Il permet notamment de conserver… track de tous les défauts, bogues multiples, erreurs et autres anomalies détectées 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 Ce type de rapport permet de prendre connaissance de tous les défauts et problèmes présents dans le logiciel. Il permet également d'identifier la cause d'un bug afin d'utiliser la meilleure méthode pour le corriger. Il contribue ainsi à économiser du temps et de l'argent.ping vous repérez les bugs et les problèmes.
Pourquoi devriez-vous vous soucier de 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.
- Les équipes modernes utilisent Jira, Linear ou Azure DevOps peut également lier les rapports de bogues aux tickets de sprint et aux pipelines de déploiement, garantissant ainsi traccapacité à gérer les flux de travail QA et DevOps.
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 du bug en question.tracSystème King. 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 bugs-tracComposants du roi 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é :
Toutefois, se contenter d'indiquer le titre dans le rapport de bogue ne suffit pas. Si votre titre est insuffisant, vous pouvez ajouter un court 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] à la boutiqueping « J’ai ajouté l’article à mon panier, mais rien ne s’est passé lorsque j’ai cliqué sur le bouton « Ajouter » sur la page de présentation du produit. »
6) Étapes à reproduire :
Lors du signalement d'un bogue, il est important de préciser les étapes permettant de le reproduire. Il convient également d'inclure les actions susceptibles de provoquer ce bogue. Évitez toute formulation générique.
Soyez précis sur les étapes à suivre :
Voici un exemple de procédure bien écrite :
Étape:
- Sélectionnez le produit X1.
- Cliquez sur Ajouter au panier.
- 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 corriger le défaut dans le 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.
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 rédaction de rapports de bogues. Veillez à n'inclure aucun fait inutile ou non pertinent.
- 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.
- Utilisez les fonctionnalités de triage assistées par l'IA dans Jira ou Linear pour classer automatiquement la gravité, suggérer les doublons et acheminer le rapport vers le responsable du composant approprié.
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é.
- Jira
- luminaires Néon Del
- Azure DevOps
- Bug Zoho Tracker
- Bugzilla
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 vous contentez pas de décrire ce qui ne va pas |
| Par exemple : Pour commencer, vous devrez ouvrir votre navigateur et saisir l'adresse du site. URLVous constaterez que le premier champ, « nom d'utilisateur », est 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 trouve pas que le design de l'interface utilisateur de la page d'accueil soit réussi. | 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.
