Indicateurs et dérives

Pourquoi avoir des indicateurs ?

Les indicateurs sont particulièrement demandés et utilisés. ils servent à piloter, mesurer, chiffrer des ressentis et même à définir des contrats!

Ces indicateurs font d’ailleurs souvent l’objet d’objectifs… Ce qui tourne généralement à des dérives car, comme le dit bien la loi de GoodHart:

« lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure »

Afin de s’en convaincre je vous propose de faire l’exercice sur divers indicateurs communément utilisés dans le test (cela peut se faire sur n’importe quel type d’indicateur: lié ou non au test)

Indicateur 1: le nombre de bugs

But: Cet indicateur est souvent utilisé en test et a pour objectif de déterminer la qualité d’une application. Instinctivement, on se dit que plus il y a de bugs, moins la qualité est bonne.

Objectif fixé: on peut par exemple penser à un objectif de pas plus de 10 bugs détectés sur une nouvelle version en production.

Dérives: Le nombre de bugs peut vite être trompeur… Voir même contourné. En effet, on peut supprimer le messager (ou plus simplement diminuer la durée des tests pour en faire moins). Il est également possible de ne pas créer les fiches de bug (ce qui est courant dans certaines équipes Agile). On peut même décider de fusionner des bugs en indiquant qu’en fait c’est la même anomalie. Enfin, on ne parle pas de criticité des bugs!

Indicateur 2: le nombre (ou %) de tests automatisés

But: connaitre l’avancement de l’automatisation des tests

Objectif fixé: on peut par exemple fixer cet objectif à 1 test automatisé par jour et par automaticien

Dérives: Les dérives sur cet indicateurs sont nombreuses. J’en ai personnellement vécu une sur un projet. L’objectif d’automatisation était élevé et au final nous n’avions automatisé que des tests « triviaux » et peu pertinents… Sans compter que nous avions également automatisés des tests très semblables. Au final, seules 1 ou 2 fonctionnalités étaient couvertes… Mais l’indicateur était au vert :(. Cet indicateur peut donc vite mener à l’automatisation de test qui ne sont pas pertinents à automatiser.

Indicateur 3: un pourcentage de test en succès

But: estimer la qualité de l’application

Objectif fixé: On peut par exemple fixer cet objectif à 90% de test en succès.

Dérives: Avec cet indicateur on peut rapidement multiplier des tests qui sont sûrs de passer et on ne repère pas les tests de mauvaise qualité. De plus, même si ce n’est pas une dérive 90% de test en succès ne veut rien dire. Cela peut dire des anomalies mineures sur des parcours rares mais aussi une fonctionnalité totalement KO (exemple: impossible d’aller dans les options)

Indicateur 4: La criticité des bugs

But: connaitre l’impact d’un bug sur la qualité de l’application

Objectif fixé: on peut par exemple fixer un objectif de 0 bug majeur livré en production

Dérive: afin d’assurer une mise en production il est possible de « requalifier des bugs » en diminuant la criticité…

Indicateur 5: le nombre de bug exécuté par jour

But: connaitre l’avancée de la campagne

Objectif: on peut par exemple fixer un objectif de 10 bugs par jour et par testeur

Dérive: on peut décider de faire les tests les plus rapides ou passer moins de temps sur les re-test afin d’assurer le suivi

Indicateur 6: la vélocité

But: connaitre la capacité d’une équipe à délivrer des fonctionnalités

Objectif: fixer un objectif de vélocité est une dérive en soi. On peut pourrait par exemple demander une augmentation de la vélocité ou une vélocité proche de la moyenne des différentes équipes (oui, je sais, ça pique comme objectif)

Dérive: outre que la vélocité est un indicateur lié à une équipe et non comparable entre les équipes (car valeurs relatives), donner un objectif de vélocité à une équipe ne peut qu’aboutir à une sur-évaluation des User Storys afin d’assurer l’atteinte de cet objectif. Cela rend donc les estimations caduques et dénuées de sens (au delà de l’inflation engendrée). Un vélocité varie, fluctue en fonction de la vie de l’équipe!

Bref, je pourrais continuer ainsi pendant des pages…

Au final, que faut-il retenir ?

Les indicateurs sont des outils précieux. Ils permettent de donner beaucoup d’informations! Néanmoins il faut faire attention avec les indicateurs et ne pas les ériger en totem. Les indicateurs ne sont que des chiffres et des mesures. Individuellement ils sont facilement contournables!

C’est pourquoi, lorsque l’on travaille avec des indicateurs il faut avant tout travailler avec plusieurs indicateurs qui fonctionnent bien ensemble mais aussi faire des investigations lorsqu’un indicateur donne des résultats inattendus. En fait, c’est comme un test en échec, cela ne donne que peu (pas) d’information tant qu’il n’est pas analysé!

Et vous, quelles sont vos expériences avec les indicateurs ?

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles