Le taux de couverture ne protège personne
Quatre-vingts pour cent de couverture et une prise de commande cassée en production, ça existe. J'en ai vu.
La couverture mesure les lignes de code traversées. Elle ne dit rien du parcours qui fait entrer l'argent. Une suite qui teste très bien vos utilitaires de formatage de dates et jamais votre tunnel de paiement affiche un excellent chiffre et ne vous protège de rien.
La bonne question n'est pas « quel pourcentage ? ». C'est « quels parcours ne doivent jamais casser ? »
Choisir les parcours
Trois questions suffisent à établir la liste, et elle est toujours plus courte qu'on ne le croit.
Par où passe l'argent ? Inscription, ajout au panier, paiement, confirmation. Ce chemin-là d'abord.
Qu'est-ce qui déclenche les appels au support ? Vos tickets sont une carte de vos points de rupture, gratuite et déjà écrite.
Qu'est-ce qui ne peut pas être rattrapé ? Un affichage tordu se corrige le lendemain. Une commande perdue ou un mail de confirmation jamais parti, non.
Sur la plupart des produits, ça donne entre cinq et quinze scénarios. Pas cinq cents. Une suite de cinq cents tests que personne ne regarde vaut moins que huit tests que tout le monde surveille.
Trois anneaux, pas un seul
L'erreur classique, c'est de tout mettre au même endroit du pipeline.
Anneau 1, la barrière de pull request. Les parcours critiques, et rien d'autre. Objectif ferme : moins de dix minutes. Au-delà, les développeurs apprennent à passer autour, et une barrière qu'on contourne n'est plus une barrière.
Anneau 2, le smoke après déploiement. Les mêmes parcours, rejoués sur l'environnement réel juste après la mise en production, avec la vraie configuration et les vrais services tiers. C'est cet anneau qui attrape les erreurs de configuration, et elles sont plus fréquentes que les régressions de code.
Anneau 3, la surveillance en production. Les deux ou trois parcours qui portent le chiffre d'affaires, rejoués toutes les quinze minutes sur la production, en continu. C'est la seule chose qui répond vraiment à « zéro régression en production », parce que c'est la seule qui regarde la production.
Tester en production sans la salir
C'est l'objection qu'on me fait à chaque fois, et elle est légitime.
Un compte de test dédié, marqué comme tel dans la base, exclu des statistiques et de la facturation. Des données créées puis supprimées par le test lui-même. Sur les paiements, une carte de test du prestataire, ou un arrêt du scénario juste avant le débit, ce qui couvre déjà quatre-vingt-dix pour cent du risque. Et une convention de nommage qui rend le nettoyage possible même après un échec.
Ça se conçoit en une journée. Ça évite d'apprendre une panne par un client.
L'ennemi, c'est l'instabilité
Une suite qui échoue au hasard une fois sur dix est pire que pas de suite du tout. Au bout de trois semaines, l'équipe relance sans lire, puis fusionne sans attendre. Vous payez le coût et vous n'avez plus la protection.
La discipline qui marche : un test instable est mis en quarantaine le jour même. Il sort de la barrière, il garde son ticket, il est réparé dans la semaine. Ce qu'il ne faut jamais faire, c'est le désactiver silencieusement. C'est ainsi que les suites meurent, un `skip` à la fois.
L'indicateur à suivre
Pas le nombre de tests. Pas le pourcentage de couverture.
Le délai entre le moment où le parcours casse et le moment où vous le savez.
Sans rien, ce délai vaut le temps qu'un client mette à vous écrire. Avec l'anneau 3, il vaut un quart d'heure. C'est toute la différence, et c'est le seul chiffre qui mérite d'être au mur.
Ce que ça ne remplace pas
La détection n'est pas la correction. Savoir en quinze minutes que le paiement est cassé ne sert que si vous pouvez revenir en arrière vite. Un déploiement réversible et des drapeaux de fonctionnalité sont l'autre moitié du dispositif.
Les tests vous disent quoi. Le rollback décide de combien ça coûte.