Tests et QA : la preuve contre l'intention

6.1 Le principe, en une ligne

Un test prouve ce que le code fait. Votre intention ne prouve rien. Toute la discipline consiste à remplacer « je suis à peu près sûr que ça marche » par « voici la preuve que ça marche ».

6.2 Les niveaux qui existent vraiment

Le contrôle de build : est-ce que ça compile. Si ça ne build pas, ça ne part pas. Le type-check : attrape une classe d'erreurs avant que quoi que ce soit ne s'exécute. Le lint : règles de style et de qualité. Le test unitaire : une fonction isolée. Le test de bout en bout : un vrai trajet utilisateur simulé dans un navigateur. Le test de fumée : une vérification rapide en conditions réelles juste après le déploiement, comme le point d'entrée qui répond ou le paiement qui débite le bon montant. La QA humaine : une personne qui déroule une checklist sur les trajets complexes (paiement, emails, tâches planifiées) avant une mise en ligne. Vous n'avez pas besoin de tous dès le premier jour. Vous avez besoin de savoir lesquels un changement donné exige.

6.3 Les faux rouges, et pourquoi ils coûtent aussi cher que les faux verts

Tout le monde s'inquiète du test qui passe alors qu'il ne devrait pas, le faux vert (Loi 5). L'inverse est tout aussi dangereux : un test qui échoue alors que rien ne va mal, le faux rouge. Un faux rouge vous entraîne à ignorer le contrôle. Après la troisième fois où un verrou crie au loup, vous cessez de le lire, et il ne protège plus rien, même quand il a raison. Un contrôle instable n'est pas un désagrément mineur. C'est un contrôle en route vers la désactivation.

6.4 Ce que la QA humaine fait et que les tests ne feront jamais

Les tests automatisés vérifient ce que vous avez pensé à vérifier. Une personne qui déroule le parcours remarque ce à quoi vous n'avez pas pensé : la formulation qui embrouille, l'état qui semble faux, la chose qui fonctionne techniquement mais qu'aucun utilisateur ne comprendrait. Sur les chemins d'argent en particulier (paiements, remboursements, tout ce qui a un effet financier réel), vous validez en mode test réel, avec un vrai événement, pas en lisant le code et en raisonnant que ça devrait aller. Raisonner n'est pas prouver.

6.5 Comment prouver qu'une garde garde vraiment

Quand vous ajoutez un contrôle de sécurité, prouvez qu'il garde comme vous prouveriez n'importe quel invariant : donnez-lui la mauvaise entrée exprès et confirmez qu'il bloque. Une garde que vous n'avez jamais vue qu'en train de passer est une garde que vous n'avez pas testée. C'est encore la Loi 5, braquée cette fois sur votre propre code de sécurité.

6.6 Testez tôt, dès la première tranche

L'erreur de test la plus coûteuse, c'est de tester tard. Si vous construisez dix tranches avant de faire tourner l'ensemble de bout en bout, une casse dans la tranche un reste cachée jusqu'à la tranche dix, et vous voilà à déboguer à travers neuf couches pour la trouver. Faites tourner le vrai trajet dès que la première version fine existe. Un bug attrapé à la tranche un, c'est cinq minutes de correction. Le même bug attrapé à la tranche dix, c'est un après-midi.