Corriger une anomalie en la reproduisant d’abord avec un test qui échoue

## Déterminer quelle partie du système est responsable de l’anomalie avant de toucher au code Partez de l’impact observable, et non du fichier dans lequel le symptôme est apparu. Une qualification utile indique à la personne qui poursuit l’enquête ce qui a échoué, qui ou quoi est concerné et quel composant est responsable du comportement. ### Classer avant d’agir - Classez l’anomalie comme relevant du comportement central, du comportement du système ou d’une intégration, ou encore de l’environnement hôte. - Distinguez le composant qui affiche le symptôme de celui qui contrôle le comportement défaillant. - Transférez le travail vers la frontière responsable lorsque les preuves indiquent que la cause se trouve hors du composant actuel. ### Définir le périmètre des preuves Consignez l’entrée déclenchante, l’état initial, les actions exactes de l’utilisateur, le résultat attendu, le résultat réel et l’environnement pertinent. Séparez les faits des hypothèses. Ne modifiez pas le code d’implémentation pendant la qualification ; l’étape suivante doit d’abord établir un échec reproductible. La classification est provisoire. Si des preuves ultérieures la contredisent, revenez à cette étape, révisez la frontière et déplacez le test vers la couche réellement responsable du comportement. ## Reproduire ce que voit l’utilisateur avec un test qui échoue Transformez le signalement en scénario reproductible aussi court que possible tout en restant fidèle à l’expérience de l’utilisateur. Conservez les éléments significatifs de l’entrée, de l’état, de la séquence et du résultat visible ; retirez la préparation accessoire qui n’influe pas sur l’échec. ### Choisir la couche de test fiable la plus proche - Utilisez un test unitaire ou de composant ciblé pour une logique isolée. - Utilisez un test d’intégration ou de système lorsque la persistance, le rendu, le transport ou plusieurs composants interviennent. - Utilisez un test dans un navigateur ou de bout en bout lorsque l’échec dépend d’une interaction réelle, du focus, du temps, de la navigation ou de l’état visuel. Écrivez le test de régression avant de modifier le code source. Exécutez-le et confirmez qu’il échoue pour la raison signalée, et non à cause d’une préparation défectueuse, de ressources obsolètes, de données manquantes ou d’une assertion sans rapport. Un test dont l’échec n’a jamais été observé ne constitue pas une preuve de l’anomalie. Si le comportement ne peut pas être automatisé, expliquez pourquoi et consignez la solution de remplacement reproductible la plus probante, par exemple une procédure manuelle déterministe, une série de captures d’écran, une trace ou une sortie mesurée. Ne modifiez pas le code d’implémentation tant que les preuves de l’échec ne sont pas fiables. ## Trouver le premier point où le comportement dévie et isoler la cause racine Ne commencez l’enquête qu’une fois la reproduction de l’échec stabilisée. Formulez plusieurs hypothèses plausibles et testez-les par des observations ciblées au lieu de modifier plusieurs éléments à la fois. ### Suivre la première divergence Suivez l’entrée défaillante à travers les changements d’état, les frontières et le flux de contrôle. Comparez un cas réussi au cas défaillant et trouvez le premier point où le comportement réel diverge du comportement attendu. N’examinez les artefacts générés, les valeurs persistées, les réponses d’intégration ou le minutage que si la reproduction indique qu’ils sont pertinents. Pour chaque hypothèse, prédisez les preuves qui la confirmeraient ou la rejetteraient, exécutez la plus petite vérification permettant de les distinguer et consignez le résultat. Distinguez la cause racine des dommages en aval et des conditions qui rendent simplement l’anomalie plus facile à observer. Ne modifiez pas la logique de production pendant l’isolement de la cause. Si toutes les hypothèses échouent, revenez à la reproduction, vérifiez ses postulats, affinez la classification et formulez une nouvelle hypothèse appuyée par des preuves. ## Appliquer le plus petit correctif et garder le test contre les régressions Une fois la cause racine isolée, modifiez la plus petite surface permettant de rétablir le comportement attendu. Préservez les contrats publics et les comportements sans rapport, et évitez tout nettoyage, toute reconception ou toute restructuration qui ne serait pas nécessaire au cas défaillant. Exécutez d’abord le test qui échouait à l’origine. Il doit désormais réussir parce que la cause a été supprimée, et non parce que l’assertion a été affaiblie, que le scénario a été ignoré ou que le jeu de données de test n’exerce plus l’anomalie. Conservez ce test comme protection permanente contre les régressions. Exécutez ensuite le groupe de tests directement concerné ainsi que les vérifications statiques, stylistiques ou de types pertinentes. N’élargissez la vérification à un ensemble plus vaste que si la modification traverse des frontières partagées ou si les preuves ciblées révèlent un risque plus large. Traitez chaque nouvel échec comme une preuve : corrigez une véritable régression ou revenez à l’isolement de la cause racine si le correctif proposé était incomplet. Examinez les modifications finales afin de repérer les changements accidentels, la logique dupliquée, la validation affaiblie et les cas limites manquants. À cette étape, le correctif n’est complet que si le comportement ciblé et les vérifications directement voisines réussissent. ## Refaire le parcours de l’utilisateur dans un environnement réel avant de déclarer l’anomalie corrigée Les tests automatisés sont nécessaires, mais ils ne remplacent pas la confirmation du parcours réel de l’utilisateur. Répétez la procédure d’origine dans un environnement d’exécution représentatif, avec les mêmes entrée et état significatifs qui ont révélé l’anomalie. Comparez les résultats avant et après à la frontière visible. Le cas échéant, confirmez aussi le résultat persisté, la sortie rendue, l’événement émis, le transfert d’intégration ou l’artefact reconstruit dont l’utilisateur dépend en définitive. Consignez l’environnement, les étapes et le résultat observé afin qu’une autre personne puisse vérifier la conclusion. Si le comportement manuel échoue encore, diffère du résultat automatisé ou exige un contournement non documenté, ne déclarez pas l’anomalie résolue. Revenez à la classification ou à la reproduction, adaptez le test pour couvrir la condition oubliée et répétez la boucle cause, correctif, régression et validation. Terminez par un rapport de preuves concis : classe de l’anomalie, reproduction confirmée, cause racine, modification minimale, couverture de régression, vérifications directement concernées et résultat du parcours réel. N’ajoutez une règle de prévention réutilisable que si l’anomalie révèle une famille architecturale récurrente ; laissez les détails ponctuels dans le test et l’historique des modifications.