3. Évaluer les tests sur le coût total du logiciel
3.1 L’objection du manque de temps
Les objections courantes sont la pression des échéances, le temps nécessaire pour écrire les tests et la conviction que son entreprise possède des contraintes trop particulières. Christian Desrosiers explique avoir lui-même défendu ces idées au début de sa carrière. Il les présente comme des préjugés à confronter aux résultats observés.
Le raisonnement à éviter consiste à comparer uniquement « coder sans test » et « coder avec un test » sur les prochaines heures. Si l’absence de protection mène ensuite à des enquêtes, des correctifs urgents et des clients insatisfaits, ce travail fait partie du coût réel. Être continuellement occupé à réparer les bogues peut justement rendre nécessaire l’investissement qui permettra d’en sortir.
Les bénéfices visés sont la qualité du logiciel, la satisfaction des clients, la réduction des demandes de soutien et la maintenabilité. L’automatisation ajoute la possibilité de refaire la vérification rapidement et fréquemment.
3.2 Pourquoi une grande suite manuelle ne suit pas la livraison continue
Une anecdote décrit une entreprise où une version attendue en trois mois exigeait environ six mois de validation manuelle. Les procédures remplissaient des cartables et une équipe devait exécuter les clics prescrits. Chaque fonctionnalité supplémentaire ajoutait des scénarios à la pile.
Ce modèle ne permet pas de valider chaque livraison quotidienne. L’accumulation des procédures rend le cycle de plus en plus long, malgré le nombre de personnes engagées pour l’exécuter. Automatiser les scénarios répétitifs permet de les rejouer sans refaire à chaque fois le même travail humain et réduit la documentation procédurale nécessaire à ces répétitions.
L’exemple vise cette dépendance à une validation systématique lourde. Il ne supprime pas tous les besoins des autres familles de tests ou de l’observation humaine; la stratégie globale reste complémentaire.
3.3 Six mois plus tard ou cinq minutes plus tard : la chaîne de coût
Supposons qu’un changement crée une régression découverte par un client six mois après. Le signalement passe par le soutien; il faut comprendre et reproduire le problème, rechercher la modification responsable, trouver une personne qui connaît cette zone, corriger, produire une version et la livrer. Plusieurs acteurs sont mobilisés avant même la correction.
L’auteur du changement a aussi perdu le contexte mental qu’il possédait pendant le développement. Il doit recharger sa compréhension des interactions et des raisons du code. La mémoire de travail et les interruptions comptent dans ce coût : revenir sur un mécanisme complexe ne se réduit pas à rouvrir le fichier.
Si les tests signalent la régression cinq minutes après l’intégration, la personne connaît encore le changement et son intention. Le client n’a pas subi le problème et la chaîne de soutien n’a pas été déclenchée. Une erreur qui aurait coûté beaucoup de coordination peut être corrigée rapidement par son auteur.
Sans protection, une correction peut aussi réintroduire un autre problème : régler B casse A, puis rétablir A casse B. Cette alternance use l’équipe et les clients. À l’échelle de milliers de changements, une rétroaction proche du changement représente une économie importante.
3.4 Confiance et coût des modifications
Une suite pertinente et verte réduit le stress des mises en production. Elle aide à vérifier qu’un refactoring ou une nouvelle fonctionnalité n’a pas détérioré des comportements existants. Le gain porte sur la capacité à décider et agir avec davantage de confiance, pas sur une certitude absolue que le logiciel ne peut contenir aucun bogue.
Lorsque le code devient un château de cartes, les développeurs évitent de le toucher et le client attend plus longtemps les améliorations. La dette technique est comparée à une carte de crédit dont on paie sans cesse les intérêts sans diminuer le capital : de plus en plus de travail sert à gérer la fragilité. Un concurrent qui ne possède pas ce bagage peut évoluer plus vite. La protection par les tests et l’amélioration de la structure contribuent donc aussi à la valeur client et à la compétitivité.