« Retour

5 graphiques Jira pour mieux communiquer sur les anomalies

Avoir les bonnes métriques au bon moment

« Combien a-t-on d’anomalies ouvertes ? »

Voilà une question que les testeurs entendent souvent, 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.

Un backlog 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 !

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 demandes »

Priorité des bugs

Le graphique « Statistiques de demandes », très simple, permet de visualiser une facette donnée d’un lot de demandes. Ici, nous avons choisi la priorité 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.

NB : Jira, contrairement à Bugzilla ou Mantis, ne comporte pas de champ « Sévérité » ou « Impact ». C’est un reproche que l’on peut faire à la plateforme, car en pratique un bug de sévérité mineure peut être prioritaire par rapport à un bug de sévérité majeure. En revanche, il est possible de contourner cette limitation en créant un champ personnalisé.

Statut des bugs

Voici ci-dessus un autre exemple d’application du graphique « Statistiques de demandes », portant cette fois sur l’état des demandes. Un nombre élevé d’anomalies rouvertes peut indiquer une fréquence importante de régressions, ou une attention insuffisante portées aux corrections. Un graphique a toujours besoin d’une interprétation ; le testeur est aussi là pour ça.

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, un testeur affecté depuis quelques temps à un projet donné saura où focaliser son 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 bugguée ! »

Le graphique « Plage de demandes » 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 nouveaux testeurs, 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.

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.

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...

Réunion de clôture : un jeu pour finir en beauté !

Testeur en contexte Agile

Un avis ? Un commentaire ?

Cet espace est pour vous.