La pyramide des tests, sans jargon.

Vous connaissez peut-être ce sentiment. On modifie quelque chose dans votre système, et une semaine plus tard, on découvre qu'entre-temps, autre chose s'est cassé alors que cela fonctionnait sans problème depuis des mois. Chaque nouvelle modification ressemble donc à un pari, et une nouvelle version devient un moment qu'on redoute au lieu de l'attendre avec impatience.

Ce n'est généralement ni de la malchance ni une question de personnes négligentes. C'est le symptôme de l'endroit où les tests se font. Et c'est justement quelque chose que vous pouvez évaluer, même si vous n'écrivez pas de tests vous-même.

Il existe pour cela une image bien pratique : la pyramide des testsLa pyramide des tests est une règle empirique pour tester un logiciel : beaucoup de petits tests rapides et automatiques à la base, et de moins en moins de grands tests lents à mesure que l'on monte.. Imaginez une pyramide à trois niveaux. En bas, large et solide, se trouvent de très nombreux petits contrôles qui vérifient chacun un petit morceau du logiciel. Ils tournent automatiquement et en quelques secondes, et on les relance donc à chaque modification. Au milieu, il y a des contrôles moins nombreux mais plus grands, qui vérifient que les différentes parties fonctionnent bien ensemble. Tout en haut, dans la pointe étroite, se trouve une poignée de contrôles qui parcourent toute l'application comme le ferait un utilisateur. Ces derniers sont précieux, mais lents et fragiles, c'est pourquoi on en garde volontairement peu.

La forme, c'est tout l'enjeu. Elle est large et bon marché en bas, étroite et coûteuse en haut. Certaines équipes retournent cette pyramide sans le vouloir. Elles n'automatisent presque rien et contrôlent surtout à la fin, en cliquant sur tout à la main juste avant une nouvelle version. Cette construction bancale porte un surnom moqueur, le cornet de glace : un tout petit peu de solidité en bas et une grosse boule lourde au-dessus. C'est lent, ça casse facilement, et ça laisse passer précisément les erreurs sur lesquelles personne n'est tombé par hasard en cliquant.

Si tester à la base rapporte autant, ce n'est d'ailleurs pas une question d'opinion. C'est le même raisonnement que la loi de BoehmLa loi de Boehm dit qu'une erreur coûte d'autant plus cher que vous la découvrez et la corrigez tard, et que ce coût augmente de façon exponentielle. : plus vous découvrez une erreur tard, plus elle coûte cher à corriger, et la facture grimpe vite. Une erreur qu'un petit contrôle automatique repère dès l'écriture du code ne coûte presque rien. Si cette même erreur n'apparaît que chez vos clients, elle coûte plusieurs fois plus cher, sans compter la confiance que vous perdez au passage.

Qu'est-ce que cela signifie concrètement pour vous ? Vous n'avez pas besoin d'écrire ni de lire le moindre test. Il suffit de poser la bonne question à ceux qui développent ou maintiennent votre logiciel : comment testez-vous, et cela se fait-il automatiquement à chaque modification ou seulement à la main à la fin ? La réponse vous en dira plus que vous ne le pensez. Une équipe qui répond calmement que la plupart des contrôles tournent automatiquement vous offre une tout autre perspective qu'une équipe qui explique passer quelques jours à tout vérifier manuellement avant chaque nouvelle version.

Et si vous voulez creuser : on reconnaît une approche saine au fait que sortir une nouvelle version est un geste banal plutôt qu'un événement. Là où la pyramide est dans le bon sens, les gens osent faire des modifications, car ils savent tout de suite quand quelque chose se passe mal. Là où elle est à l'envers, on touche au système le moins possible de peur de casser quelque chose, et c'est précisément cette prudence qui rend un système plus cher et plus rigide à terme.

Vous n'avez donc pas besoin de devenir testeur pour en tirer parti. Il suffit de savoir que cette forme de pyramide existe, et de demander de temps en temps si, chez vous, elle tient toujours debout.