Pourquoi le code sans bug n'est pas le bon objectif
Tout système comporte des défauts que personne n'a encore rencontrés, et le coût pour trouver le suivant augmente fortement à mesure que les plus évidents sont éliminés. Passé un certain seuil, une heure de plus passée à traquer les défauts vaut moins que la même heure consacrée à rendre les défaillances peu coûteuses à détecter et à corriger.
Le second problème est culturel. Quand le code sans bug est l'objectif affiché, un bug devient un échec qu'il faut justifier plutôt qu'une information sur laquelle agir, et l'on en parle de moins en moins.
Trois objectifs qui fonctionnent
Zéro récidive
Un bug donné ne survient qu'une fois. Chaque correction laisse un contrôle derrière elle.
Atteignable, et cumulatif.
Détecté avant les utilisateurs
Déplacer la détection de la production vers la pull request.
Mesurable : la part de défauts détectés en interne.
Peu coûteux à corriger
Le délai entre la défaillance et la correction, qui dépend surtout de la qualité du rapport d'échec.
Pourquoi le premier compte le plus
Une équipe qui ne livre jamais deux fois le même bug s'améliore mécaniquement chaque mois. Cela n'exige qu'une seule habitude : quand vous corrigez quelque chose, laissez un contrôle derrière vous. La plupart des équipes corrigent le bug, ferment le ticket et ne gardent aucune trace du fait que ce comportement avait besoin d'être protégé.
La mesure
Suivez la part des défauts détectés avant la mise en production et le délai entre la défaillance et la correction. Les deux bougent quand quelque chose s'améliore réellement, et aucun des deux ne se manipule en écrivant davantage de tests : c'est là tout leur intérêt. Le nombre de tests et le pourcentage de couverture, eux, augmentent à la demande et ne vous apprennent presque rien.
Pourquoi les équipes continuent malgré tout de le poursuivre
Savoir que l'objectif est mauvais n'empêche personne de le viser, et la raison mérite d'être comprise, car elle est structurelle et non naïve.
Les bugs sont visibles, la prévention ne l'est pas. Un défaut qui a atteint un client a un ticket, un nom et un responsable. Les douze qui ont été interceptés avant la mise en production n'ont rien, parce qu'il ne s'est rien passé. Le bilan visible d'un trimestre est donc une liste d'échecs, et la réaction naturelle face à une liste d'échecs est d'en exiger moins.
La parade consiste à rendre la prévention visible elle aussi. Communiquez le nombre de défauts interceptés avant la mise en production à côté du nombre de ceux qui sont passés. Le premier chiffre est généralement bien plus élevé, et le voir fait passer la discussion de « pourquoi avons-nous toujours des bugs ? » à « est-ce que le ratio évolue ? », qui est la question dont la réponse est utile.
À quoi cela ressemble en pratique
Chaque bug donne lieu à un contrôle. Les contrôles s'exécutent à chaque changement plutôt qu'avant les mises en production. Les défaillances arrivent sous une forme exploitable, sans que la personne qui corrige ait à reconstituer l'histoire.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Le tableau de bord couvre le même périmètre pour qui ne veut pas d'installation locale, et l'ensemble des commandes se trouve dans le dépôt CLI.
Le déclencheur compte plus que le mécanisme. Le brancher sur votre événement de déploiement garantit que chaque changement est contrôlé sans que personne ait à le décider ; la GitHub App s'en charge depuis le tableau de bord, et une étape GitHub Actions le fait depuis l'intérieur de votre workflow.
Comment TestSprite sert ces trois objectifs
Le zéro récidive est celui qu'il sert le plus directement. Le cas de test qui a reproduit un bug reste dans le projet et s'exécute à chaque changement : la correction laisse donc un contrôle derrière elle sans que personne ait à penser à l'écrire.
La détection avant les utilisateurs est une question de cadence. La couverture est générée à partir de votre produit et s'exécute sur la pull request, ce qui ramène la détection de la production vers le changement qui en est la cause.
Le coût de correction dépend du rapport d'échec. Une exécution vous revient sous la forme de ce qui a été tenté, de ce qu'a fait l'application et de l'endroit où les deux ont divergé : la personne qui corrige, de plus en plus souvent un agent de code, part donc de preuves plutôt que de reconstituer l'histoire.
Le code sans bug est-il parfois atteignable ?
Pour de petits systèmes formellement spécifiés, on s'en approche, à un coût que presque personne ne peut justifier. Pour un produit ordinaire, non.
Quel est un taux de défauts raisonnable ?
Comparez-vous à votre propre tendance plutôt qu'à un chiffre du secteur. La direction compte plus que le niveau.
Tester davantage signifie-t-il moins de bugs ?
Jusqu'à un certain point. Au-delà, les tests supplémentaires ajoutent de la maintenance sans ajouter de signal, surtout s'ils reproduisent ce que vous couvrez déjà.
Faut-il suivre le nombre de bugs ?
Suivez les défauts qui ont échappé à la détection et le délai de correction. Les compteurs bruts augmentent quand le signalement s'améliore, ce qui en fait un mauvais signal.
Quelle est l'habitude qui a le plus d'impact ?
Laissez un contrôle derrière vous chaque fois que vous corrigez quelque chose. C'est la seule habitude dont les effets se cumulent.
Visez le zéro récidive, pas le zéro bug.
Le code sans bug est inatteignable et fausse les priorités. Visez le zéro récidive, la détection avant les utilisateurs et le faible coût de correction. Laissez un contrôle derrière chaque correction et mesurez les défauts qui ont échappé à la détection plutôt que le nombre de tests.