Les radins calculent le coût uniquement en terme d’argent. Mais si vous voulez un logiciel parfaitement testé, il faut considérer le tableau dans son ensemble.
C’est la grande question de cette série de 12 articles sur les tests unitaires pour les managers (en anglais). Ceci est l’épisode 11.
Voilà comment je vois les choses. Mais puisqu’il s’agit d’un sujet nouveau pour moi, j’apprécie vos commentaires.
- Le but de votre société est de gagner de l’argent
- Pour gagner de l’argent il faut produire un logiciel qui fonctionne (soit pour le vendre soit pour que des utilisateurs internes en fassent bon usage)
- Pour produire des logiciels stables et bien testés il faut une bonne équipe (pour qui les tests comptent plus que d’ajouter 1000 fonctionnalités)
- Pour avoir une bonne équipe il faut plus que de l’argent
Une comparaison
Comparons 3 types de tests que vous devez sûrement déjà pratiquer : les tests unitaires (auto), les tests d’intégration (manuels), les tests de régression (manuels).
[table id=1 /]
Bon d’accord, ce n’est pas très objectif… Mais ça reflète bien ce que j’ai collecté comme information sur différents projets.
Un exemple
Cette semaine, j’ai passé 2 jours à automatiser le plus de tests possible dans la fonction que je développe.
Je pensais que mon application était simple et tenait la route avant de mettre des tests partout, même sur les classes les plus triviales.
Mais j’ai découvert des bugs ! Parfois de simples erreurs de copier/coller. Parfois plus grave.
J’ai donc commencé à automatiser les 208 tests que je faisais encore à la main. Nous avons gagné plus que 2 jours de correction de bugs grâce à ça.
J’ai aussi économisé de l’argent en augmentant mes connaissances du produit (les cas de tests) et des tests en général (JUnit, Mockito,…).
Le chef de projet était d’accord pour passer ces 2 jours supplémentaires à coder les tests et à réusiner quelques classes. Et je suis sûr qu’il a pris la bonne décision. Bien sûr les esprits chagrins diront qu’on ne le saura jamais. Tant mieux.
Le coût du débogage
Parfois déboguer semble plus rapide qu’implémenter des tests unitaires. Et dans l’absolue ça peut être le cas.
Mais soyons honnêtes : si vos campagnes de tests nécessitent plusieurs personnes pendant des jours, le coût de telles campagnes crève le plafond.
Les campagnes de ce type (nécessaires mais coûteuses) se déroulent souvent comme ça :
- Préparer un environnement de test (recette) pour les testeurs et les développeurs qui corrigent
- S’assurer que les testeurs utilisent la bonne version des spécifications (parfois les ‘écrire à rebours si elles manquent !)
- Quand un testeur trouve un bug (qui aurait pu être évité par 3 lignes de JUnit…) il rempli un rapport
- Le chef de projet reçoit le rapport, test pour vérifier les dires de son estimé collègue et assigne le bug à un développeur
- Le développeur cesse tout ce qu’il fait et essaye de reproduire le bug, le corrige et test à nouveau
- (Si le développeur est bon il implémente immédiatement un test automatique pour éviter de trouver ce bug manuellement à jamais)
- Retour au chef de projet pour validation
- Retour au testeur pour validation
TODO
- Rendez-vous dans votre Excel favori et tachez de calculer vraiment combien vous perdez d’argent en laissant vos équipes faire des tests à la main
- Revenez sur cette page et dîtes-nous que vous allez investir plus dans les tests unitaires. Nous serions ravis de débattre sur des cas concrets.
- Demandez-vous honnêtement : quel est le coût de ne PAS faire de tests unitaires automatiques
Pour les développeurs
Quelle est votre opinion sur le sujet ? Pensez-vous que votre chef est radin(e) sur les tests unitaires ? Quel est le risque à ne payer que pour du manuel ?
