Garder les preuves avant de relancer le test

Un test illustratif ouvre une page de paramètres, soumet une modification et échoue car la valeur attendue n'apparaît jamais. Quelqu'un publie la dernière capture d'écran. Il montre un panneau vide. L'utilisateur a-t-il été déconnecté ? La demande de sauvegarde a-t-elle échoué ? L'assertion s'est-elle heurtée à un mauvais enregistrement ? L'image ne peut à elle seule répondre à ces questions.

Un échec de test est une séquence, pas une photographie. Cet article propose un petit ensemble de preuves qu'un ingénieur QA ou un développeur peut lire sans répéter toute l'exploration. L'objectif est de réduire les investigations évitables, et non de collecter tous les octets possibles ou de promettre un diagnostic automatique.

Commencez par l'action et son contexte

Trace Viewer de Playwright vous permet d'inspecter une trace de test enregistrée avec une chronologie d'action et des instantanés associés. Sa documentation décrit l'examen de la source, des erreurs, de la sortie de la console et de l'activité réseau. Ces vues répondent à différentes questions : ce que le test a tenté, ce que la page a montré et ce que l'application a échangé. Une capture d'écran reste utile, mais il s'agit d'une vue à l'intérieur d'un paquet plus grand.

Enregistrez l'identifiant du test, la révision du code, l'environnement, le rôle du compte initial et l'assertion qui a échoué. Décrivez l'état attendu avec des mots simples. Gardez les secrets hors de la description. Les preuves doivent indiquer quel rôle intermédiaire a été utilisé, et non publier un cookie de session ou l'identité d'un véritable client.

Le transfert en cinq champs

Utilisez cinq champs pour chaque échec : résultat attendu, résultat réel, première étape défaillante, emplacement de la trace ou de l'artefact et conditions de reproduction. Sous résultat réel, distinguez une réponse d'erreur reçue d'une absence de contenu visible. Sous certaines conditions, notez l'enregistrement prédéfini pertinent et si un test parallèle aurait pu le modifier.

Ne laissez pas l'explication d'un agent remplacer la preuve originale. Un récit confiant est une hypothèse jusqu'à ce que le journal des actions ou l'état de l'application le prenne en charge. Marquez les causes suspectées comme suspectées. Si l'artefact n'est pas disponible, indiquez cet écart plutôt que d'écrire une séquence plausible à partir de la capture d'écran finale.

Ce format aide les deux types d'équipes. Un responsable du contrôle qualité reçoit un transfert révisable au lieu d'un mur de texte généré. Une entreprise sans ingénieur QA dédié est confrontée à un incident qu'un autre développeur peut détecter après que le testeur d'origine ait quitté le bureau. Ni l'un ni l'autre n'a besoin d'une cause fondamentale fictive pour paraître complète.

Choisissez quand collecter une trace

Les options de test de Playwright documentent les modes de trace, notamment la conservation d'une trace en cas d'échec et l'enregistrement lors de la première tentative. Le choix compte. Une trace de première tentative enregistre cette tentative ultérieure, qui peut se comporter différemment de l'échec d'origine. Si des preuves de la première tentative sont nécessaires pour un flux critique, ne présumez pas qu'un enregistrement de nouvelle tentative uniquement les contient.

Choisissez une stratégie d'artefact pour chaque classe de risque et vérifiez qu'elle produit réellement le fichier nécessaire. La capture de chaque exécution peut coûter du temps et du stockage. En capturer trop peu peut coûter cher à une enquête. Mesurez ces coûts sur votre suite au lieu d'adopter une règle universelle issue d'une démo.

Protégez le paquet avant de le partager

Les traces et les captures d'écran peuvent contenir le contenu de la page et demander des détails. Utilisez des données intermédiaires synthétiques, limitez l'accès aux artefacts et définissez une fenêtre de conservation. Vérifiez le contenu réel avant de partager une trace en dehors de l'équipe. La suppression d'un nom de fichier qui semble sensible ne supprime pas la session ou les données personnelles contenues dans le fichier.

La page publique d'AnyTest décrit les observations à chaque étape et les raisons de l'échec. Il s'agit d'un contexte de produit utile, mais cela ne veut pas dire que sa sortie est identique à une trace Playwright. Séparez les formats de preuves des fournisseurs et vérifiez ce que le coureur que vous avez choisi conserve réellement.

Mesurez l'enquête, pas le nombre de captures d'écran

Lors d'un pilote, enregistrez les minutes depuis la première panne jusqu'à une description reproductible, puis jusqu'à une cause confirmée. Séparez le temps passé à récupérer les artefacts manquants du temps passé à réparer le produit. L'assurance qualité agentique permet de gagner du temps d'enquête uniquement si les preuves sont utilisables et que l'examinateur peut faire confiance à leur provenance. Mieux vaut un paquet plus petit qui répond à la question qu'une grande archive que personne n'ouvre.