Comment rédiger un rapport de bogue.

Le succès de tout projet dépend en grande partie des compétences de l’équipe. Une équipe solide a un mélange de compétences techniques et non techniques et, plus important encore, une communication bien établie entre ses membres, construite autour d’un fort esprit d’équipe.

Dans cet article, nous partagerons notre approche de la rédaction de rapports de bogue et révélerons notre modèle de rapport de bogue. Les testeurs doivent fournir une description du bogue dans un format clair et structuré, ce qui permet aux développeurs de reproduire, comprendre et corriger rapidement le bogue. La communication et les rapports de bogues simples accélèrent le développement du projet.

Selon Wikipedia, bug — En informatique, un bug (prononcé en français : /bœg/note 1) ou bogue est un défaut de conception d’un programme informatique à l’origine d’un dysfonctionnement.

En d’autres termes, les bugs sont une vraie douleur pour chaque projet. Ils pourraient entraîner divers problèmes, tels que la publication tardive de l’application, l’échec d’une campagne de marketing, une réputation endommagée ou l’existence même du projet.

Un rapport de bogue est un document technique qui contient toutes les informations nécessaires sur le bogue et les conditions dans lesquelles il peut être reproduit. Il s’agit d’un guide destiné aux développeurs et à l’équipe engagés dans la résolution du bogue.

Tout le monde peut rédiger un rapport de bogue, mais chaque rapport de bogue est-il efficace? Généralement l’équipe QA rédige des rapports de bogues détaillés, ce qui permet à toute l’équipe de publier des projets avec succès.

Il existe deux critères principaux pour un rapport de bogue bien rédigé:

Reproductibilité. Dès que le développeur a vu et reproduit l’erreur, elle peut être corrigée. Sans reproductibilité, les bogues peuvent rester inchangés.

Clarté et valeur d’information. La description doit contenir le minimum de texte, mais fournir autant d’informations que possible. Un “essai” approfondi ne peut que dérouter le développeur.

N’oubliez pas que chaque rapport de bogue renvoyé au testeur avec le statut “Ne peut pas être reproduit” ou “Informations requises” est une perte de temps totale pour le testeur et le développeur. C’est pourquoi il est crucial de fournir un rapport de bogue de haute qualité et bien rédigé.

Nous vous recommandons d’utiliser un modèle de rapport de bogue approuvé par l’équipe au début du processus de travail. Vous pouvez le créer en utilisant de bons vieux tableaux Excel, mais nous vous suggérons d’utiliser des systèmes de suivi des bogues.

Selon le système de suivi des bogues, votre modèle peut différer. Cependant, les champs suivants sont obligatoires:

TitreGravité / prioritéLa descriptionEnvironnementÉtapes à suivre pour reproduireRésultat attenduRésultat actuelPièces jointes (captures d’écran, vidéos, texte)

En plus des champs de rapport de bogue requis, vous pouvez ajouter plus de détails en fonction du projet, des préférences des développeurs et du Product Owner.

Numéro de rapport unique (ID)

La plupart des systèmes de suivi des bogues attribuent automatiquement un identifiant à chaque bogue.

Auteur

La plupart des systèmes de suivi des bogues ont ces informations par défaut, vous pouvez donc contacter rapidement le testeur qui a trouvé et décrit le bogue.

Assigné à

Cette section spécifie les informations sur le développeur qui corrigera le bogue. En fonction des accords et de l’organisation du projet, le bogue peut être attribué à un QA ou un PM senior qui décidera quel développeur doit le corriger.

L’état qui montre l’étape actuelle de travail avec le bogueDate de création

Titre

Le premier et le plus important attribut de tout système de suivi des bogues est une brève description du problème, qui vous permet de naviguer rapidement sur le problème et de le décrire avec un simple «Quoi? Où? Lorsque?”

Par example:

Quelle? — La photo ne se charge pas.

Où? — Dans la section “Profil”.

Sous quelles conditions? — Appuyez sur le bouton “Télécharger depuis la galerie”.

Gravité et priorité des bogues

À première vue, ces attributs semblent être les mêmes, mais ils ne le sont pas. Regardons de plus près.

Gravité du bogue
La gravité décrit l’effet du défaut sur les performances de l’application, par exemple:

Bloqueur. Une erreur qui provoque l’échec de l’application.
Critique. Un défaut critique qui entraîne l’échec de certaines fonctionnalités clés.
Majeur. Une erreur cruciale qui indique un écart par rapport à la logique métier ou qui perturbe le programme, mais qui n’a pas d’impact vital sur l’application.
Mineur. Un défaut mineur qui ne viole pas les fonctionnalités de l’application lors du test, mais qui influence le résultat attendu. Une erreur de conception en serait un exemple.
Banal. Un bogue qui n’affecte pas la fonctionnalité ou le fonctionnement de l’application mais peut être détecté visuellement, par exemple, une faute de frappe dans le texte.

Priorité aux bogues
La priorité spécifie l’ordre dans lequel le problème doit être résolu. Nous utilisons la gradation générale suivante pour cela:

Haute. Tout ce qui a un impact sur le flux utilisateur typique ou bloque l’utilisation de l’application.
Moyen. Tout ce qui affecte négativement l’expérience utilisateur.
Mineur. Tout le reste (fautes de frappe, icônes manquantes, problèmes de mise en page, etc.).

La description

Cette partie développe le champ Titre car assez souvent la table des matières devient trop lourde. C’est là que le champ de description est utile, vous pouvez donc décrire le problème sans aucune restriction. Il spécifie également des conditions supplémentaires, telles que la fréquence à laquelle l’erreur se produit, si l’erreur est accidentelle et les circonstances qui pourraient la provoquer.

Par example:

REMARQUE: le fuseau horaire du compte = GMT + 1

Dans certains systèmes de suivi de bogues, tels que Jira, ce champ comprend également des éléments tels que l’environnement, les étapes à reproduire, le résultat attendu, le résultat réel et même les pièces jointes.

Environnement

Une application peut avoir un comportement incohérent selon la situation, vous devez donc ici décrire en détail toutes les conditions dans lesquelles un bogue est reproduit, par exemple:

Fabricant de l’appareil et numéro de modèle
Version du système d’exploitation
Version de l’application
Connectivité réseau
Orientation de l’écran
Le navigateur
Par example:

Appareil — macOS Mojave.

Version du système d’exploitation — 10.14.6.

Navigateur — Google Chrome Version 90.0.4430.212 (Build officiel) (x86_64)

Étapes à suivre pour reproduire

Cet élément doit contenir les étapes minimales décrivant le chemin complet de la reproduction du bogue. Décrivez une étape par ligne.

Par example:

Condition: l’utilisateur est inscrit dans le système.

Accédez à la liste des produits proposés.

Ajoutez le produit “A” au panier.

Appuyez sur Acheter.

Gardez simplement à l’esprit que des étapes évidentes ne sont pas nécessaires. Par exemple, vous n’avez pas besoin de spécifier: Ouvrez l’application et connectez-vous, sauf si le problème est directement lié à ces actions.

Résultat attendu

Assurez-vous de décrire le résultat attendu en fonction de la tâche technique, de la conception, du résultat des cas de test ou de l’opinion du testeur. De cette façon, le développeur saura exactement sur quoi se concentrer et ne perdra pas son temps à rechercher les informations nécessaires.

Par example:

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

Résultat actuel

Ce champ décrit l’effet réel du bogue. Parfois, les testeurs écrivent des instructions générales telles que le bouton Annuler ne fonctionne pas correctement. Ce n’est pas très instructif, n’est-ce pas? Le bouton est-il enfoncé? L’action ne s’annule-t-elle pas? Ou une autre action non liée à l’annulation se produit-elle?

Il est très important d’écrire une description claire du résultat réel. Dans la plupart des cas, il coïncide avec le titre.

Par example:

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

Pièces jointes

Il est courant de joindre des fichiers aux rapports de bogue car il est plus facile de percevoir les informations lorsqu’elles sont affichées visuellement.

Par example:

Capture d’écran (c’est pratique lorsque le bogue est mis en évidence avec un cercle ou une flèche),Vidéo (parfois, il peut être difficile de décrire le bogue avec des mots, il vaut donc mieux le voir par vous-même).Fichier journal.

Vous vous demandez peut-être si quelque chose ne va toujours pas, même si vous utilisez le modèle. Voici quelques recommandations pour rédiger un rapport de bogue efficace:

N’ayez pas peur de demander de l’aide au chef de projet ou à votre lead si quelque chose n’est pas clair pour vous.Assurez-vous de demander des commentaires et des suggestions aux développeurs concernant vos rapports de bogues. Chaque projet est unique, chaque développeur est différent et il est crucial de trouver la bonne approche. Une atmosphère confortable et une compréhension mutuelle entre les membres de l’équipe contribuent à un travail rapide et de qualité.Relisez le rapport de bogue avant de le sauvegarder. Vous pourriez même le faire deux fois.Assurez-vous que le rapport de bogue contient la description d’une seule erreur.Ne critiquez pas et ne blâmez pas vos collègues. Les erreurs sont inévitables et elles ne sont pas toujours faciles à détecter ou à corriger. N’oubliez pas que vous êtes une équipe!Répétez l’erreur plusieurs fois, corrigez les étapes et ajoutez plus de détails si nécessaire.