Ayant occupé le rôle de chef d’équipe de test sur de nombreux projets au cours de ma carrière, j’ai vu pléthore de rapports de bugs. Grâce à cette expérience, je peux vous dire qu’un mauvais rapport de bugs, en plus d’apporter peu de valeur, coûte un temps précieux, quelque chose que la plupart des projets n’ont pas les moyens de s’offrir, surtout que de plus en plus d’entreprises adoptent des pipelines d’intégration et de déploiement (CI/CD) continus. Pour une équipe, il n’y a rien de plus frustrant, pendant le triage, que de devoir renvoyer un bug au testeur en raison d’informations confuses ou incomplètes.
Un rapport de bugs clair et percutant impressionnera le lecteur par son importance, aidant l’équipe du projet à facilement comprendre l’impact du bug et le classer selon sa priorité. Pouvoir rapidement classer un bug selon sa priorité aide l’équipe du projet à décider comment, où et quand allouer des ressources pour un correctif.
Un bug se voit attribuer la plus haute priorité quand il a un impact sur la plupart des utilisateurs ou des fonctionnalités essentielles pour l’application en général, demandant une attention immédiate. La priorité est également déterminée par l’ampleur de l’impact qu’un bug potentiel peut avoir sur l’expérience client ou les revenus nets de l’entreprise. Ainsi, même si un bug a l’air en apparence mineur, il pourrait avoir un impact bien plus important pour le client.
Le travail d’un testeur est de trouver les bugs, d’écrire un rapport clair et concis, d’évaluer la sévérité du problème en se basant sur les connaissances de l’application testée, de fournir des étapes de reproduction détaillées et d’inclure des preuves concluantes. Tout commence avec le titre du bug.
1. Un titre clair et concis
Un rapport de bugs percutant donne immédiatement une idée claire du problème, rien qu’avec le titre.
« Y’a une erreur » est probablement le titre le plus inutile que je n’ai jamais vu. Cela ne nous dit rien, à nous et au client. En tant que chef d’équipe de test, je renverrais directement ce rapport au testeur et lui demanderais de l’améliorer.
Voici un exemple de titre plus ou moins convenable :
« Erreur Java Runtime lorsque l’on sélectionne Payer dans le panier »
Ce titre fournit au moins une idée de la teneur du problème. Je pourrais choisir la priorité selon son impact, si les détails du bug contiennent assez d’informations. Cependant, si je teste dans plusieurs types d’environnements, ce titre seul ne me dit pas si le problème existe dans tous les environnements ou un seul. Je renverrais également cela pour avoir plus d’informations.
Un titre percutant doit contenir autant d’informations que possible sur le problème. Des informations telles que l’environnement de test, le domaine du test, le nom du cas de test, l’étape du test et le problème :
« Web – Paiement – TC 1802 – BUY EGC – Étape 4 –Erreur Java Runtime lorsque l’on sélectionne Payer dans le panier »
Rien qu’en lisant le titre, je peux directement comprendre quel est le problème et où il se trouve, tout en ayant une idée précise de son importance.
Bien sûr, selon le logiciel que vous utilisez le suivi des bugs, il se peut que vous soyez limité par le nombre de caractères que vous pouvez saisir ou qui sont visibles dans une vue rapide de la liste de bugs. Si c’est le cas, faites de votre mieux pour offrir des informations aussi concises que possible dans le titre.
Maintenant que nous avons un titre clair et concis, passons au corps de notre rapport de bug.
2. Une définition détaillée du problème
Le corps du rapport de bugs donne autant de détails que possible concernant le problème. Comme pour le titre, « Y’a une erreur » n’est pas une information utile. Ayant déjà mis autant d’informations concises que nous pouvions dans le titre, la description doit contenir une analyse plus détaillée du problème. Cela pourrait inclure :
- Un résumé du problème comprenant des détails techniques ou des termes plus simples – ceci est utile quand certaines des personnes impliquées n’ont pas de profil technique
- Nom/identifiant du cas de test où le problème a été trouvé. Cela est utile si le cas de test est obsolète et doit être actualisé pour refléter l’état des fonctionnalités actuelles
- Les étapes de test exactes pour reproduire le problème
- Les résultats attendus (ce qu’il devrait se passer)
- Les résultats réels (ce qu’il se passe vraiment)
3. Preuves et documentation
Nous avons donné plus de détails concernant le problème et avons fourni les étapes pour le reproduire. Que pouvons-nous encore ajouter au rapport de bugs ? De la documentation. Ajouter les preuves suivantes, si c’est possible, aidera l’équipe à définir rapidement la priorité et permettra au développeur de trouver la racine du problème de façon efficace :
- Texte d’erreur (et identifiant de l’erreur si disponible) si une erreur est affichée
- Environnement de test où le problème a été trouvé (assurez-vous de noter si le problème peut être reproduit dans tous les environnements du test, certains mais pas tous ou seulement un seul)
- Captures d’écran ou vidéo montrant les étapes menant au bug
- Logs (appareil, crash, réseau, etc.) enregistrés au moment du problème et qui peuvent aider les développeurs à cibler le problème plus rapidement
- Le nombre de fois que le problème a été reproduit (parfois un problème peut être légitime mais intermittent)
- Toute autre preuve pouvant être incluse
Félicitations ! Vous avez maintenant écrit un rapport de bugs percutant que l’équipe et les développeurs peuvent utiliser pour comprendre, assigner la priorité, identifier et, plus important encore, corriger le problème.
Si vous avez des questions spécifiques sur l’écriture de rapports de bugs percutants, contactez notre équipe. Nos chefs d’équipe de test modifient et trient des milliers de rapports de bugs chaque semaine, et nous sommes spécialisés dans la création des rapports de bugs que les équipes de développement peuvent facilement comprendre, et avec lesquels ils peuvent travailler sans encombre.
6 min