Qu’est-ce qui fait un bon rapport de bogue ?
Les rapports de bogue sont la devise de l’assurance qualité. Ils sont le produit de notre travail et, pourrait-on dire, la validation de notre existence. En règle générale, ils sont le seul canal d’information entre le testeur et le développeur.
Pour cette raison, il est assez important que nous les obtenions correctement. Un mauvais bug est un obstacle plutôt qu’un atout et peut causer toutes sortes de méfaits :
- Ils orientent mal les développeurs, font perdre du temps
- Ils frustrent les développeurs, sapant la confiance dans l’assurance qualité
- Ils donnent une fausse impression de l’état général d’une construction
- Ils perturbent les outils de modélisation conçus pour déterminer les dates d’achèvement
- Ils gênent le reste de l’équipe QA qui doit les corriger
Rédiger un rapport de bogue n’est pas un art, c’est de la science. Ce qui fait qu’un bon rapport de bogue peut sembler être une question à laquelle il est facile de répondre, et si vous l’abordez du point de vue d’un développeur, la réponse est généralement quelque chose comme : “Un bon rapport est quelque chose que nous n’avions pas repéré et est facile à réparer.”
Les testeurs ont un point de vue différent. Nous évaluons la qualité des données contenues dans le rapport lui-même plutôt que le bogue qu’il décrit. C’est le type de “bon bug” dont nous parlons maintenant.
Nick Barrett, PDG de Proper QA
Compréhension instantanée
Idéalement, un développeur ouvrira un rapport de bogue, le scannera pendant une nanoseconde et comprendra immédiatement le problème exact qu’il décrit.
Si un bug doit être lu plusieurs fois alors que le front des développeurs devient de plus en plus sillonné, c’est un échec. S’il doit être retourné à QA pour que des informations supplémentaires soient demandées, c’est une catastrophe.
L’uniformité engendre l’anonymat
Il y a généralement un champ de données dans chaque rapport de bogue affichant le nom du testeur qui a soumis le bogue. Cela devrait être le seul moyen d’identifier le testeur.
Les bogues doivent être écrits dans un style uniforme qui suit une norme commune.
Si un développeur peut identifier un testeur par le style dans lequel un bogue a été écrit, alors soit ce testeur fait quelque chose de mal, soit tous les autres testeurs le font !
Les langages de programmation suivent des règles de formatage rigides. S’ils ne le faisaient pas, le code ne fonctionnerait pas. Les rapports de bogues ne sont pas si inflexibles, mais ils ne sont pas l’endroit pour exprimer l’individualité ou un flair artistique pour le langage. Nous devons fournir toutes les informations pertinentes de la manière la plus concise possible.
Toute personne qui lit un rapport de bogue doit en comprendre facilement le contenu, quel que soit son rôle dans l’organisation.
C’est un scénario frustrant lorsque nous voyons un sous-ensemble de bogues qui n’ont presque jamais été soumis par QA, qui ne peuvent pas être triés par la production, traduits, réaffectés, régressés et fermés par QA, car ils sont l’équivalent d’un chiffrement à deux lignes message écrit pour que seul l’auteur puisse le comprendre. Des notes comme celle-ci peuvent avoir leur place mais ce n’est pas une base de données de bogues.
Les rapports de bogues ne sont pas le lieu pour exprimer l’individualité ou un flair artistique pour le langage
Éléphants dans le noir
Vous connaissez peut-être la parabole de trois aveugles qui tentent de conceptualiser à quoi ressemble un éléphant en utilisant simplement leur sens du toucher. Chaque individu ressent une partie différente de l’animal. Leurs descriptions sont limitées par leurs expériences uniques et n’ont de sens que pour eux-mêmes. Il s’agit d’un défaut courant avec les rapports de bogues mal rédigés, en particulier lorsqu’ils sont rédigés par une personne autre qu’un testeur (utilisateur final, développeur, stagiaire, etc.).
La recherche de bugs représente 50% de la vocation du QA. L’autre moitié est la communication. Si un bogue ne peut pas être communiqué correctement au développeur, cela crée un nouveau problème plutôt que d’aider à la solution.
Les bogues nécessitent un résumé succinct et descriptif distinct des étapes de recréation, semblable à un titre de journal : “C’est un éléphant”.
La description doit ensuite répertorier toutes les étapes nécessaires pour forcer le bogue à se manifester sans contenir de données superflues
Une image vaut mille descriptions de bogues mal écrites
Si la manifestation d’un bogue est visible à l’œil nu, il faut une capture d’écran, une vidéo ou les deux. Il en va de même pour tout ce qui peut être exprimé à l’aide d’un graphique, d’un tableau, d’un fichier audio, d’une liste de résultats, etc.
Lorsque vous reproduisez un bogue, le défaut est souvent évident, car vous le regardez directement, ce qui conduit à la tentation de ne pas le capturer en vidéo parce que c’est tellement évident, n’est-ce pas ?
Les développeurs ne devraient pas avoir à lancer le logiciel et à recréer le bogue eux-mêmes
Tort. Les développeurs ne devraient pas avoir à lancer le logiciel et à recréer le bogue eux-mêmes. Le catalyseur pour exiger cette action provient souvent d’un manque d’images appropriées jointes aux rapports de bogues.
Lorsque quelqu’un essaie d’expliquer quelque chose et que votre réaction est un regard d’incompréhension, votre réponse suivante est presque toujours : “Montre-moi”. Ce n’est jamais plus vrai que dans un rapport de bogue. Téléchargez ces pièces jointes !
Les bugs sont des blessures dans votre logiciel
Souffrir d’une blessure “mineure” ne signifie pas nécessairement qu’elle n’est pas prioritaire, et parfois une blessure “majeure” n’est pas de la plus grande urgence à traiter.
Les hôpitaux évaluent les patients entrants de cette façon et nous devrions trier les bogues entrants en utilisant la même méthode ; attribuer à chaque nouveau bogue une cote de priorité basée sur toutes les informations soumises par le testeur.
La gravité est une classification technique immuable du bogue. La priorité est une décision commerciale en constante évolution.
En 2014, Assassin’s Creed: Unity avait brièvement un bug qui ne rendait pas les visages des personnages
La sévérité est une valeur attribuée par le testeur et la meilleure pratique est d’utiliser une échelle alphanumérique… Evitez d’utiliser des adjectifs descriptifs trop ouverts à l’interprétation. Trouvez un ensemble de valeurs et définissez-les. Par exemple, tous les plantages peuvent être de “classe A” et toutes les fautes de frappe peuvent être de “classe C”. L’important est que les valeurs ne changent pas une fois que vous avez déterminé votre plage.
La priorité est une valeur attribuée par le développeur en fonction de l’urgence pour l’entreprise de résoudre le bogue. Les testeurs ne peuvent pas choisir une cote de priorité car ils ne savent pas à quel point ce bogue est important pour vous. Le rôle du testeur est d’inclure suffisamment d’informations pour que le destinataire par défaut de tous les nouveaux bogues puisse les trier rapidement, attribuer une note de priorité et attribuer le bogue au développeur le plus approprié.
Utiliser un logiciel de gestion de bogues approprié
L’emailing c’est pour les mails. Les DM sont pour flirter. Twitter est l’équivalent Internet de crier par la fenêtre. Aucun de ces outils n’est approprié pour rapporter des bogues.
La traçabilité et la propriété des bogues est sans exagération, l’un des aspects les plus importants du cycle de vie d’un bogue. Il ne manque pas d’excellents logiciels de gestion de bogues disponibles, souvent peu coûteux ou gratuits. Vous pouvez même trouver un plugin disponible pour adapter l’un de vos outils logiciels existants pour le rapport de bogue.
La traçabilité et la propriété des bogues sont l’un des aspects les plus importants du cycle de vie d’un bogue
Votre métier est la création de logiciels. C’est un outil dont vous avez besoin pour faire ce travail de la meilleure façon possible. Il existe des versions logicielles réussies qui ont évité une base de données de bogues dédiée, mais pour chacun d’entre eux, il y en a un millier qui ont échoué, ou ont traversé une lutte facilement évitable et ont brûlé beaucoup de travail supplémentaire inutile sur leur chemin vers le succès.
“Mais c’est encore une autre chose que nous devons gérer et à laquelle nous devons nous connecter” est un argument qui est invalidé très rapidement par les inconvénients de ne pas en utiliser un.
Amorcez le canon anti-insectes et préparez-vous à tirer !
Le pire rapport de bogue est celui qui n’a jamais été écrit. Parfois, cela est dû au fait qu’un bogue n’a pas été trouvé, ce qui peut être attribuable à des cas de test mal écrits ou manquants, à des tests insuffisants ou à des testeurs de qualité inférieure/non formés (les développeurs entrent carrément dans cette catégorie !)
Pire que ce scénario dans un bogue non signalé qui était réellement connu.
Un testeur dit : “Oh, ouais, je n’ai pas écrit celui-là parce que le développeur a dit qu’il travaillait déjà dessus.” Inacceptable… Bug quand même. La traçabilité est primordiale.
Un testeur dit: “Ah, eh bien, je pensais que c’était déjà buggé.” Ils auraient dû confirmer leurs soupçons en recherchant dans la base de données de bogues avant d’appeler pour ne pas signaler le bogue.
Un testeur dit : “Eh bien, je n’arrivais pas à déterminer si c’était un bug ou par conception.” Bien, mais bug quand même. Le risque commercial qu’un bogue ne soit pas signalé éclipse complètement le risque de causer à un développeur l’inconvénient trivial de trier un bogue et de le supprimer “comme prévu”.
En cas de doute : bug it !
Je frissonne quand je lis les mots “je pense” dans un rapport de bogue. Personne ne se soucie de ce que vous pensez, seulement ce que vous savez
Soyez factuel
L’ambiguïté est une denrée sans valeur à la bourse des bogues et il ne faut pas l’acheter : les bogues doivent être exclusivement composés d’énoncés factuels.
Je frissonne quand je lis les mots “je pense” dans les étapes de recréation d’un rapport de bogue. Personne ne se soucie de ce que vous pensez, seulement de ce que vous savez. Soit vous savez, soit vous ne savez pas. Est-ce mesurable et démontrable ?
La validité découle de choses qui peuvent être prouvées de manière démontrable en utilisant la mesure et la répétition.
Les expressions du type “ça se passe pendant quelques secondes” ou “je l’ai vu brièvement” ou “ça se manifeste de temps en temps” sont inacceptables. Mesure le. Combien de secondes ? Définissez “brièvement”. Enregistrez un pourcentage de la fréquence à laquelle il se manifeste.
Ce sont les perceptions des testeurs qui les amènent à signaler des bogues, mais paradoxalement n’ont pas leur place dans un rapport de bogue. Faits, chiffres, statistiques, données. Rien d’abstrait ou d’ambigu ne devrait en tenir compte.
Les déclarations identifiant une faute sans exprimer pourquoi elle a été déterminée comme une faute doivent également être interdites. « Cet élément n’est pas de la bonne couleur », « la résolution est mauvaise », « le menu ne fonctionne pas » sont sans valeur isolément et ouverts à un contre-argument. Nous devons citer l’exigence de conception ou mettre en évidence une comparaison contradictoire avec une fonctionnalité identique ailleurs dans le logiciel.
Pour citer le professeur qui m’a initié aux mathématiques à l’âge de 6 ans : “Montre ton fonctionnement !”
Découvrez d’avantage plus d’articles dans nos catégories Astuce, Consoles ou encore Jeux.
Merci pour votre visite on espère que notre article Qu’est-ce qui fait un bon rapport de bogue ?
, pour nous aider, on vous invite à partager l’article sur Facebook, pinterest et whatsapp avec les hashtag ☑️ #Questce #qui #fait #bon #rapport #bogue ☑️!