Fermer

septembre 22, 2021

Rapports de bogues — Écrire pour un public


Des personnes dans au moins trois rôles différents peuvent lire votre rapport de bogue, et les informations dont chaque groupe a besoin sont différentes. Je vais vous montrer comment organiser votre rapport afin qu'il fournisse tout ce dont votre public a besoin.

Lorsque vous écrivez quelque chose, il est important de tenir compte du public pour lequel vous écrivez. Diverses parties prenantes liront le rapport de bogue, et chacune aura besoin de différents niveaux d'information. Les rapports de bogues doivent être rédigés pour aider toutes les parties prenantes à trouver les informations dont elles ont besoin afin que la décision correcte puisse être prise quant à savoir si et comment le bogue doit être corrigé.

Dans cet article, nous allons voir qui lit souvent les rapports de bogues. et de quelles informations ils ont besoin. Nous passerons ensuite en revue quelles informations doivent être incluses dans un rapport de bogue et comment elles doivent être présentées, afin que toutes les parties prenantes puissent trouver les informations dont elles ont besoin.

Qui lit les rapports de bogue ? seront trois principales parties prenantes qui liront les rapports de bogue :
  1. La personne qui révise le bogue
  2. La personne qui corrige le bogue
  3. La personne qui teste la correction de bogue

La personne qui révise le bogue peut être un chef de projet, une entreprise analyste ou quelqu'un qui comprend le mieux les besoins de l'entreprise et du client. Ils décident si le bogue est bien un bogue, s'il doit être corrigé et quand il doit être corrigé.

Un bogue de faible gravité peut être reconnu comme devant être corrigé, mais n'ayant pas besoin d'être corrigé immédiatement. Ce bogue sera probablement ajouté à un backlog et éventuellement récupéré par un développeur pour être corrigé. Un bogue de gravité élevée est susceptible d'être signalé comme devant être corrigé immédiatement. Il sera ajouté en haut de la liste des travaux à effectuer.

La personne examinant le bogue n'aura pas besoin d'autant d'informations que la personne qui corrige ou teste le correctif. Certaines des informations plus détaillées, comme les étapes pour les reproduire, ne sont pas toujours nécessaires lors de l'examen du bogue. Parfois, ils peuvent regarder les informations supplémentaires pour plus de contexte, mais une brève description leur suffit généralement pour décider si le bogue doit être corrigé ou non. Pour aider ceux qui révisent les bogues à le faire rapidement, le rapport de bogue doit commencer par une brève description qui les aide à comprendre le bogue.

Les personnes qui corrigent et retestent le bogue ont besoin d'informations plus détaillées comme les étapes pour le reproduire et les informations sur l'environnement de test. . Ces informations sont essentielles pour le débogage et pour bien comprendre la nature du bogue.

La présentation du rapport doit être telle que les informations requises par tout le monde – le résumé décrivant le bogue – se trouvent au début, et les informations supplémentaires soient au début. finir. Cela rendra la révision du bogue aussi facile que possible et aidera les réviseurs à prendre la bonne décision quant à savoir si et quand le bogue doit être corrigé.

Mise en page et sections à inclure dans le rapport

Ceux qui lisent un rapport de bogue devrait dicter les informations qui y sont incluses. Malheureusement, ils ne sont pas toujours au courant des informations dont ils ont besoin, donc leur demander n'est pas toujours utile. Une façon de contourner cela est de prendre note de toutes les questions de suivi qui se posent après que les parties prenantes ont lu le rapport. C'est un excellent indicateur des informations manquantes et il vaut toujours la peine de les inclure dans les futurs rapports.

Il est probable que le format et la présentation du rapport s'amélioreront avec le temps. Cependant, voici quelques sections utiles pour vous aider à démarrer.

Titre
Introduction
Sévérité/Priorité
Étapes à reproduire
Détails supplémentaires

Titre

Cela semble tellement évident. Tout a besoin d'un titre. Un mot ou une phrase brève pour que vous sachiez ce que vous êtes sur le point de lire. Le titre n'est pas seulement l'en-tête d'un document, c'est aussi ce qui apparaît dans les listes de bogues. Au début d'une session de revue de bogues, les parties prenantes seront accueillies avec une longue liste de titres de bogues. Il arrive souvent que ce soit tout ce qu'ils examinent avant de décider quels bogues examiner.

Beaucoup font l'erreur d'inclure simplement une brève description du bogue dans le titre. Imaginez que vous regardez une liste de bogues contenant des détails vagues :

  • Le bouton ne fonctionne pas
  • Le format de la page est incorrect
  • Impossible de modifier un enregistrement

Ces exemples manquent de détails et de contexte. Le titre doit fournir suffisamment d'informations pour que les parties prenantes sachent ce qu'elles regardent avant de l'avoir lu. Vous devez inclure des détails sur la fonctionnalité ou l'application testée, des éléments précis qui causent le problème et une brève description de ce que ces éléments font (ou ne font pas).

Étant donné que les titres ne peuvent pas être trop longs et sont souvent limité en longueur, fournir suffisamment de détails est un défi. La création d'un format que tous les titres doivent suivre peut servir de guide utile pour les informations utiles pouvant être fournies.

Ceci est un exemple de format de titre qui pourrait être utilisé :

[Feature/Application]—[Impacted element] [Is/is not] [Behavior]

Exemple :
Calculatrice—Le bouton Égal n'effectue pas le calcul

L'utilisation de ce format facilitera également l'organisation des listes de bogues. Les listes de bogues sont normalement organisées par gravité, puis par ordre alphabétique. Nommer la fonctionnalité impactée et la placer au début du titre permettra de regrouper les bogues ayant un impact sur la même fonctionnalité.

Introduction

Chaque rapport de bogue doit commencer par une introduction. Il s'agit essentiellement d'une extension du titre, ajoutant une certaine clarté au bogue. L'introduction ne doit inclure que deux ou trois phrases décrivant le problème. Trop d'informations et les parties prenantes auront du mal à comprendre et à examiner le problème.

Lors de l'examen initial du bogue, les parties prenantes regarderont rarement au-delà du titre et de l'introduction. S'il y a une longue liste de bogues, il se peut qu'ils ne passent pas plus de quelques minutes à décider d'accepter ou de rejeter le bogue. Nous voulons qu'ils prennent la bonne décision, nous devrions donc prendre cette décision aussi facilement que possible. Une introduction plus courte sera plus facile à comprendre et à revoir. Trop d'informations, et il y a un risque de confusion et d'incompréhension.

Alors quelles informations faut-il inclure dans l'introduction ?

Tout d'abord, nous avons besoin d'une description du bogue. Cela doit inclure à la fois le comportement actuel et le comportement attendu. Si vous incluez simplement le comportement actuel, les parties prenantes pourraient se retourner et dire : « N'est-ce pas censé se produire ? » Fournir le comportement attendu ajoutera une clarté supplémentaire à la nature du bogue. Cela supprimera également toute ambiguïté plus tard concernant ce qui doit être fait pour corriger le bogue.

Des informations supplémentaires qui peuvent être utiles aux parties prenantes peuvent inclure des détails sur qui ce bogue aura un impact et quel impact ce bogue pourrait avoir. Cela aidera les parties prenantes à comprendre la gravité du bogue. Il se peut qu'ils acceptent que ce bogue soit corrigé—cependant, quand le bogue doit être corrigé sera une autre histoire. Le bogue peut devoir être corrigé immédiatement, ou il peut être corrigé à une date ultérieure.

Un exemple d'introduction pourrait être :

Sur la calculatrice, appuyer sur le bouton égal ne parvient pas à effectuer le calcul qui a été entré . Je m'attendrais à ce que la réponse au calcul entré apparaisse sur le moniteur une fois que le bouton égal a été cliqué. Cela peut empêcher les clients d'utiliser la calculatrice pour effectuer des calculs essentiels, ce qui est son opération principale.

Toute information supplémentaire doit être ajoutée à d'autres sections du document pour que les parties prenantes puissent la lire si elles en ont besoin.

Gravité/Probabilité/Priorité

Il n'appartient pas à la personne signalant le bogue de décider si et quand le bogue doit être corrigé. Cette décision sera prise par les parties prenantes examinant le bogue. Cependant, ils s'appuieront fortement sur les informations et les conseils fournis dans le rapport de bogue.

Un nombre quantifié qui détaille la gravité du bogue selon eux est un moyen simple et efficace de fournir cette information. Il donne également aux parties prenantes une idée des bogues qui doivent être examinés en premier. Il est important de ne pas surestimer la gravité d'un bogue. Trop de bogues critiques dans une liste peuvent retarder l'examen des bogues les plus graves. Si tous les bogues sont prioritaires, aucun ne l'est. Les développeurs qui corrigent le bogue et le testeur qui est impliqué dans le retest du bogue (ce ne sera pas toujours la personne qui a initialement signalé le bogue) doivent savoir précisément comment ce bogue est répliqué afin qu'ils puissent être certains que le correctif correct a été atteint.

Cette information doit apparaître après l'introduction. La raison en est que toutes les parties prenantes qui lisent le rapport de bogue n'auront pas besoin de connaître les étapes à reproduire. Pour les parties prenantes qui souhaitent simplement examiner le ticket et décider d'approuver ou de rejeter le ticket, cette information ne sera pas toujours requise.

Les étapes à reproduire doivent uniquement être une liste d'instructions sur la façon de reproduire le problème. Peu importe à quel point le bogue peut être simple ou évident, ces détails doivent être inclus afin que nous soyons certains que tout le monde comprend la nature du bogue. Vous souhaitez également inclure ce que vous pensez que le comportement attendu devrait être et des exemples de valeurs d'entrée et de sortie pour plus de clarté.

Voici un exemple de liste d'étapes à reproduire.

  1. Allumez la calculatrice.
  2. Appuyez sur un nombre (par exemple, 3).
  3. Appuyez sur une touche d'opérations arithmétiques (par exemple, +).
  4. Appuyez sur une autre touche numérique (par exemple, 8).
  5. Appuyez sur la touche égal.
    • La ​​réponse à l'équation entrée n'apparaît pas sur le moniteur.
    • Je m'attendrais à voir la somme de l'équation.
    • Avec les exemples de valeurs de sortie fournis, je m'attendrais à voir le nombre 11 .

Informations supplémentaires

Des détails supplémentaires peuvent aider les développeurs à comprendre et à résoudre le problème. Cela peut inclure :

  • Version de l'application sur laquelle le bogue a été trouvé
  • Environnement sur lequel le bogue a été trouvé
  • Informations sur l'appareil ou le PC
  • Type et version du navigateur
  • Type d'utilisateur

Si il y a un problème avec la réplication du bogue, alors cette information peut s'avérer vitale car elle peut aider les développeurs à identifier la cause précise du problème.

Résumé

Lorsque vous décidez du format de votre rapport de bogue, il est essentiel que vous considérez votre public. L'inclusion de toutes ces informations dans la hiérarchie appropriée garantira que chacun de vos publics aura ce dont il a besoin pour faire son travail et que l'application est en bonne voie pour atteindre la perfection.

Il est probable que la mise en page et le format de votre rapport de bogue changera au fil du temps. Trouver les informations dont chacun de vos publics a besoin peut être un défi. Le moyen le plus simple est de leur demander, cependant, parfois, ils ne se connaissent pas toujours eux-mêmes. Alternativement, vous pouvez prendre note des questions qu'ils posent ou des commentaires et des modifications qu'ils apportent au rapport lui-même. Cela peut contenir des informations cachées qui peuvent vous aider à améliorer votre rapport.




Source link