Des chiffres sur le ROI des tests unitaires

le 06/09/2010 par Vincent Daubry

Le débat autour du ROI des tests unitaires et du TDD (Test Driven Development) ne date pas d'hier comme cet article du blog Octo de 2008 en témoigne :

https://blog.octo.com/le-roi-du-tdd/

Les questions soulevées sont somme-toute naturelles : même convaincu du bien fondé de cette démarche, il est toujours intéressant d'avoir une estimation de combien coûte cet investissement. Idem lorsqu'on souhaite démarrer un projet en TDD, comment intégrer cette donnée dans le chiffrage ? Doit-on prévoir +20%, +100%, rien du tout ? Les chiffres tangibles sont rares, aux questions "concrètement combien ça va me coûter en J/H ? Dans quelle proportion je vais réduire le nombre de bugs ?" on est souvent sans réponses.

Plusieurs études ont pourtant été menées sur le sujet, notamment par Microsoft. Ce dernier a publié en 2009 une étude intitulée “On the Effectiveness of Unit Test Automation at Microsoft”. Nous ferons ici un résumé des points à retenir.

1) Le contexte :

L’étude porte sur la comparaison des bugs obtenus entre la V1 et la V2 d’un projet en C#. La V1 avait été réalisée avec des tests manuels, la V2 a été réalisée en introduisant des tests unitaires automatisés (sans TDD).

On apprécie qu'il s'agisse d'un cas réel de grande envergure : 1 200 KLOC (Kilo Line Of Code) réalisé par une équipe de 32 développeurs et 15 testeurs. On notera également la durée importante de l’étude : 2 ans.

L’étude comporte 2 volets :

Des indicateurs sur l’évolution de la qualité du code
Le résultat d’une enquête auprès de l’équipe des développeurs et de l’équipe des testeurs au sujet de leur ressenti vis-à-vis de la mise en place des tests

2) Le nombre de bugs diminue

La 1ère constatation est la diminution du nombre de bugs remontés par l’équipe de tests : -20.9%. En moyenne les développeurs estiment que la mise en place des tests représente 30% de temps de développement en plus.

3) Le type de bugs évolue

Les développeurs se sentent poussés à sortir des scénarios classiques (“happy path”) et vérifier les cas limites avant d’envoyer leur développement aux testeurs.

L'équipe a le sentiment que les bugs ont changé : les erreurs grossières sont moins fréquentes. L’équipe de test doit concevoir des scénarios de test plus évolués et plus réalistes (donc plus proche du comportement d’un véritable utilisateur). Les testeurs trouvent leur travail moins mécanique et se sentent plus efficaces sur une même période de temps. Les développeurs quant à eux ont le sentiment de produire du code plus robuste.

Concernant les bugs restants, les développeurs les jugent plus faciles à corriger quand ils se situent dans du code testé.

4)Comparaison avec le TDD :

Sur le projet étudié les tests étaient écrits après les développements, tous les 2,3 jours. D’autres projets Microsoft ont obtenu de meilleurs résultats en écrivant les tests avant le code (Test Driven Development). Les projets en questions ont expérimenté des diminutions du nombre de bugs allant de -62% à -91% pour à peu prés le même coût en terme de temps investi.

P.S : .38X signifie que pour X bugs trouvés sur la V1, il n'en restait plus que 38% sur la V2. Soit respectivement des diminutions de -62%, -76% et -91%.

5) Les leçons retenues :

La mise en place de tests unitaires doit être une volonté du managment.
Le cout d’écriture et de maintenance des tests unitaires doit faire parti du budget.
La testabilité du code doit faire parti des objectifs de l’architecture et du design de l’application.
La couverture du code par les tests doit être mesurée, les résultats doivent être visibles et communiqués.
Les tests ne sont pas la propriété des développeurs : chaque membre de l’équipe doit pouvoir contribuer
L’exécution de l’ensemble des tests doit être une opération simple et rapide.