Un avis ? Un commentaire ?
Cet espace est pour vous.
Relecture 2023 : bien que cet article date un peu, nous confirmons qu’il est toujours d’actualité 😉 Bonne lecture et amusez-vous bien à créer tous les graphiques qui vous aideront dans votre quotidien de QA !
« Combien a-t-on d’anomalies ouvertes ? »
Voilà une question que les QA entendent parfois, mais qui n’amène qu’une réponse assez sommaire.
Le produit comptabilise 200 anomalies ouvertes ? Simplement en tenant compte de la criticité des bugs, on découvrira peut-être qu’il est de meilleure qualité qu’il y a quelques mois, où il n’en comptait que 150.
Une liste d’anomalies en dit long sur son projet. En prenant le temps de l’analyser, on peut être en mesure de répondre aux questions suivantes :
Autant d’informations qui permettent de détecter aussi bien des risques projet que des risques produit.
Dans votre organisation, si la gestion des anomalies se fait sur Jira, cet outil vous sera d’une grande aide pour analyser et communiquer autour des anomalies de vos projets. Il permet de créer un certain nombre de graphiques, appelés « gadgets ». En voici quelques mises en pratique !
Dans cet article nous parlons indifféremment de « demandes » ou « tickets » Jira.
Les filtres constituent une fonctionnalité phare de Jira. Ils permettent aussi bien de retrouver rapidement un lot de demandes que de créer des graphiques à partir de celles-ci.
Après avoir effectué une recherche à plusieurs critères, il suffit d’enregistrer celle-ci en lui donnant un nom. Votre filtre est prêt à être utilisé. Pour cela, rendez-vous dans l’onglet « Tableaux de bord » et cliquez sur « Ajouter un gadget ».
Le graphique « Statistiques de filtre bidimensionnel », très simple, permet de visualiser une facette donnée d’un lot de demandes. Ici, nous avons choisi en première dimension le champ dédié à la sévérité des bugs. Ce qui nuance, comme dit précédemment, le simple nombre de bugs.
Pour rappel, le lot d’anomalies est défini par le filtre choisi. Il peut être intéressant de comparer un graphique portant sur toutes les anomalies d’un projet, à un graphique portant uniquement sur les anomalies ouvertes de ce projet.
Sur ce graphique, on voit également le statut des différents bugs (la 2ème dimension), ce qui permet par exemple d’évaluer si l’effort de correction est bien dirigé vers les sévérités les plus élevées.
L’un des 7 principes généraux du test énoncés par l’ISTQB met en valeur la tendance des bugs à se regrouper. Par expérience, les QA affectés depuis quelques temps à un projet donné sauront où focaliser l’effort de test, en particulier lors de ses tests exploratoires. Mais cela ne suffit pas : il faut aussi pouvoir mettre en évidence auprès de toutes les parties prenantes les zones sensibles de l’application, afin qu’elles y accordent une attention particulière.
Sur Jira, le gadget « Carte thermique » génère un nuage de mots qui affiche chacun d’eux avec une police proportionnelle à son nombre d’occurrences. Ces mots peuvent être issus d’une multitudes de critères. Dans un projet donné, chaque anomalie peut se voir attribuer une ou plusieurs étiquettes correspondant aux blocs fonctionnels concernés. La carte thermique portant sur les étiquettes permettra alors d’identifier les fonctionnalités les plus sensibles, comme ci-dessous.
Cette vision peut aider à organiser la correction d’anomalies en mettant entre parenthèses le seul critère de priorité. Cela présente plusieurs avantages. Quand une personne se charge d’un lot d’anomalies concentrées sur une même fonctionnalité :
Comme dit précédemment, le nombre d’anomalies ouvertes peut s’interpréter de différentes façons. Il est aussi intéressant d’analyser le graphique comparant le nombre de demandes créées au nombre de demandes résolues, pour adapter si besoin l’effort de correction d’anomalies. Un gadget dédié est disponible sur Jira.
Très parlant, il permet de voir en un coup d’oeil si la dette technique est en train de se résorber ou au contraire de s’accentuer.
« Cette appli est de plus en plus buggée ! »
Le graphique « Plage de demandes », ou « Plage de tickets », permet de communiquer sur le nombre d’ouvertures de bugs au fil du temps. Prenez le temps de bien expliciter les différentes hausses et baisses, qui peuvent être dues à des facteurs très différents (nouvel interfaçage avec un autre système complexe, congés d’une partie de l’équipe, livraison de nouvelles fonctionnalités, phase soutenue de correction d’anomalies, arrivée de nouvelles recrues dans l’équipe de test, refacto…)
Pensez à désactiver l’option « cumulative ». Sans cela, le graphique afficherait une courbe croissante, qui ne permettrait pas aussi bien d’identifier les pics de bugs.
Par exemple, sur le graphique ci-dessus, nous voyons qu’entre novembre et février l’équipe a ouvert énormément d’anomalies, puis que le nombre de rapports de bugs ouvert a baissé.
Assez difficile à interpréter, ce graphique peut toutefois fournir des chiffres « choc » pour motiver la correction d’anomalies.
Un bémol cependant : ces chiffres sont de moins en moins parlants au fil du temps, car dans l’ensemble, il est normal que les bugs bloquants récents soient corrigés avant les bugs triviaux anciens.
Il peut être intéressant d’ajouter la notion de criticité à ce filtre.
Quand on considère le graphique ci-dessus, on peut supposer que le rythme de correction des anomalies a baissé et que de la dette technique s’est accumulée.
Il est important que les parties prenantes puissent accéder aux graphiques à volonté. Cela permettra à tout un chacun de prendre quand il le souhaite la température du projet. Pour cela, plusieurs solutions :
Nous espérons vous avoir donné des idées, n’hésitez pas à partager vos propres graphiques avec nous !
Testeur en contexte Agile, pour (re)découvrir le rôle des QA en contexte Scrum
L’épineuse question des KPI, parce que tous ces beaux graphiques Jira peuvent générer de précieuses métriques utiles à toute l’équipe et sa performance !
Cet espace est pour vous.