Les indicateurs sont un outil nécessaire mais dont il faut constamment se méfier. Je suis d’ailleurs revenu spécifiquement sur des exemples de dérives dans un article de décembre 2021.
Malheureusement la complexité des indicateurs ne se limite pas à leurs potentielles dérives ou la loi de Goodhart. En effet, tout comme les tests, les indicateurs dépendent du contexte… et nous l’allons montrer tout à l’heure!
Vous l’aurez compris, dans l’article d’aujourd’hui nous allons faire un jeu sur les indicateurs et déterminer si ce qu’ils remontent est bon ou non!
0 bug remonté pendant la campagne
Cet indicateur est particulièrement piégeux. Il peut laisser entendre du positif comme l’équipe a fait un super travail en prévenant les défauts. Il peut même amener à des raisonnements indiquant qu’il y a trop de testeurs et que l’on fait de la sur-qualité
Comme du négatif: les tests ne vont pas assez en profondeur ou ne sont pas assez bien ciblés.
Enfin il ne faut pas oublier que les campagnes ont des buts différents. Une campagne de tests vitaux doit détecter des régressions critiques, il est normale qu’elle remonte rarement des anomalies.
Une campagne dure moins de 5 minutes
Cet indicateur peut tout et rien dire à la fois!
Du côté positif on peut se dire que si cela dure moins de 5 minutes c’est que les tests sont sûrement automatisés et que l’on peut les inclure dans une chaîne d’intégration continue.
Du côté négatif cela peut aussi vouloir dire que l’on a une mauvaise couverture ou tout simplement que l’on est tombé sur un bug critique bloquant la campagne.
Bref là encore on dépend totalement du contexte.
100% de tests automatisés
L’indicateur du % de tests automatisés est un indicateur qui revient très souvent et que je n’apprécie pas forcément… notamment car ses dérives mènent vers une automatisation des mauvais tests. Il n’empêche que 100% est censé dire tous les tests!
Du côté positif on peut se dire que cette automatisation va faire gagner beaucoup de temps aux équipes sur l’exécution de la régression et que l’exécution manuelle ne sera faite que sous forme de tests exploratoires.
Du côté négatif, cela peut aussi vouloir dire que l’on a que trop peu de tests, que la couverture est mauvaise ou même que l’équipe passe trop de temps sur l’automatisation et qu’il n’y aura pas de retour sur investissement pour ces tests.
Enfin cela peut aussi vouloir dire que les tests non automatisables ne sont plus exécutés.
1 testeur pour 3 développeurs
C’est un nombre qui revient souvent quand on doit indiquer un nombre de testeur dans une équipe Agile et qui correspond à peu près à la moyenne des équipes comme le remonte le WQR.
Du côté positif on peut se dire que l’on est dans la moyenne et que le test n’est pas négligé.
Du côté « négatif« , cela peut se retrouver totalement en dehors du besoin. Selon les logiciels, leur complexité et leur criticité les tests doivent être plus ou moins poussés. On peut imaginer 1 testeur pour 4 développeurs pour des applications peu critiques et simple et 1 testeur pour 1 développeur pour des systèmes très critiques. De même, on parle d’équipe Agile, le « manque » de testeur peut être compensé par du travail sur le test d’autres membres de l’équipe et vice-versa.
Au final 1 testeur pour 3 développeurs est un indicateur sûrement bien pour commencer quand on ne sait pas où on va mais qui doit ensuite être adapté.
25% du budget du projet pour les tests
Cet indicateur est assez proche du précédent… et comme le précédent il a les mêmes limites… et reste un indicateur fréquemment utilisé dans les DSI. Lorsque j’ai rencontré cet indicateur pris « par défaut » pour l’ensemble des projets ce dernier était plutôt entre 19% et 22%. On peut alors se dire que 25% c’est bien.
Malheureusement cela dépend fortement du contexte comme pour le 1 testeur pour 3 développeurs. De même, ce n’est pas parce que l’on dépense « beaucoup » que l’on dépense forcément bien.
Le côté positif (en dehors de ceux évoqués précédemment) est donc que le test est bien pris en compte dans le projet avec un beau budget.
Du côté négatif cela peut aussi vouloir dire que le test n’est pas efficient (avec, par exemple des tests effectués trop tard) ou même que le budget est insuffisant dans ce contexte.
Conclusion
Je suis souvent amené à répondre à des questions de professionnels à propos d’indicateurs généraux comme ceux abordés dans cet article. Malheureusement, en l’absence de contexte et de connaissance fine de leur environnement de travail je suis incapable de répondre mieux que des généralités en mettant des pincettes comme « en moyenne » ou « on estime généralement que »…
Cela ne vient pas d’une mauvaise volonté de ma part mais bien de fait que ce qui peut être bien dans un cas ne l’est pas forcément dans un autre. Cela est également vrai sur des éléments qui pourraient être considérés comme des bonnes pratiques ou l’état de l’art.
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
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
