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 !
Avoir les bonnes métriques au bon moment
« 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 :
- Où se regroupent les défauts ?
- Comment la qualité du produit évolue-t-elle dans le temps ?
- Le nombre de régressions augmente-t-il ou diminue-t-il ?
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.
Prérequis : savoir comment gérer les filtres 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 ».
Comptabiliser une dimension des anomalies avec le graphique « Statistiques de filtre bidimensionnel »
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.
Identifier les zones à risque de l’application avec le graphique « Carte thermique »
Créer un nuage de bugs
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.
Avantages de ce graphique
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é :
- Elle termine généralement le travail plus rapidement que si plusieurs personnes s’y étaient attelé les unes après les autres
- Comme elle se plonge dans la fonctionnalité dans son ensemble, elle monte en compétence sur l’ensemble de ses aspects, ce qui pourra l’aider à la faire évoluer par la suite
- A l’issue de cette correction, le client peut se sentir soulagé de constater que pour une fonctionnalité, tout fonctionne correctement
- Des anomalies mineures ou triviales, qui auraient été ignorées sinon, peuvent être épongées.
Evaluer la dette technique avec le graphique « Demandes créées comparées aux demandes résolues »
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.
Identifier les moments critiques avec le graphique « Plage de demandes »
« 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é.
Evaluer le turn-over des bugs avec le graphique « Âge moyen »
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.
Partager les graphiques
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 :
- Insérer ces graphiques dans un ou plusieurs tableaux de bord partagés (sur Jira)
- Profiter de l’intégration Jira-Confluence pour intégrer les gadgets sur une page de wiki, ce qui permettra de commenter au fur et à mesure l’évolution des données affichées.
- Périodiquement, envoyer des rapports (par mail ou autre) intégrant des copies d’écran de ces graphiques, avec un lien pour accéder à leur version dynamique.
Nous espérons vous avoir donné des idées, n’hésitez pas à partager vos propres graphiques avec nous !
Vous aimerez peut-être…
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 !
