Mesurer la productivité d’une activité de tests logiciels

Je propose d’abord de revenir aux raisons pour lesquelles nous menons des activités de tests logiciels. De mon expérience, il s’agit en général de :

1. Trouver les défauts d’un produit, pour que les clients ne se retrouvent pas à y faire face,
2. Se faire une opinion précise sur la qualité d’un produit, par exemple pour une meilleure prise de décision,
3. Répondre aux exigences de certaines normes de produits ou services, et dans ce cas particulier, les tests vérifient une conformité.

De par sa définition, la productivité est liée au résultat obtenu. Des activités de tests que je viens de citer, le résultat en sortie serait, soit un nombre de tests exécutés, soit un nombre de défauts rendus visibles, soit les deux. Par conséquent :

• Dans le cas 1., la productivité se calculerait par un ratio rapportant le nombre de défauts identifiés chaque jour, au nombre de personnes – en équivalent temps plein – qui ont contribué à la découverte de ces défauts. C’est le cas qui convient, en particulier, aux tests automatisés.
• Dans les cas 2. et 3., cette productivité serait plutôt le ratio rapportant le nombre de tests exécutés au nombre de personnes – en équivalent temps plein – qui ont contribué à l’exécution de ces tests.

Que ce soit pour une conformité ou une idée précise sur la qualité d’un produit, ce sont les défauts – par leur présence ou non, types, caractéristiques et impacts, – qui nous permettent d’apprécier un niveau de risque pour une prise de décision. Nous faisons des tests pour trouver des défauts que le client ne trouvera pas. Ces tests sont-ils alors pertinents lorsque leur exécution ne révèle pas de défauts ? Se poser cette question récurrente, amène les testeurs à développer de nouvelles approches pour savoir où et quoi tester, dans le but de toujours trouver des défauts, et plus rapidement. Parmi ces approches, nous avons : mieux connaître l’expertise des développeurs et leurs techniques d’implémentation, s’inspirer des causes des précédents défauts, en apprendre des comportements des clients finaux, créer des tests exploratoires, démarrer par des tests non fonctionnels. Ce faisant, ils éliminent les tests inutiles, et renforcent leur valeur ajoutée qui est de trouver des défauts. Il s’agit en réalité d’une amorce d’amélioration continue de la stratégie des tests, qui est déclenchée par la recherche incessante de défauts.

Concrètement, supposons qu’après une journée de tests, la productivité de mon équipe est de 1 défaut identifié pour 10 testeurs, alors que ma cible est de 3 défauts. Si tous les tests prévus pour ce jour ont bien été exécutés, je dois affiner la stratégie pour la prochaine campagne de tests avec comme objectif d’atteindre la cible de 3 défauts. Dans le même temps, l’atteinte d’un niveau de qualité cible pour le produit à tester est définie par une checklist d’arrêt des tests. Lorsque tous les points qui y figurent sont atteints, les tests s’arrêtent. Elle contiendrait par exemple :  un nombre de tests exploratoires, de tests fonctionnels exécutés, un nombre maximum de défauts fonctionnels non bloquants, etc. Pour les testeurs, trouver des défauts est lié à leur capacité à identifier et faire de suite les bons tests et non pas à faire un gros volume de tests.

Au fur et à mesure de l’identification des défauts, les testeurs travaillent avec les développeurs pour éradiquer les causes de ces défauts. Au bout d’un certain temps, il peut devenir difficile d’améliorer la productivité en nombre de défauts parce que l’objet à tester est désormais de bien meilleure qualité. Les testeurs passent alors moins de temps à faire des tests. Véritables connaisseurs des clients et de la capacité de l’organisation à répondre à leurs besoins, ils enrichissent leur rôle, en contribuant par exemple à l’identification et à la bonne implémentation des nouvelles fonctions dont rêvent les clients.

Essayer d’améliorer une productivité liée au nombre de défauts identifiés par jour, permet d’enclencher une amélioration continue des tests et un développement personnel des testeurs.

Contactez-nous pour en savoir plus sur la productivité des tests logiciels.