// LOGICIEL
Preuve de test : pourquoi une capture ne suffit pas
6 min de lecturenijitech
La partie la plus disputée d'un rapport de test n'est pas le bug trouvé mais la question de savoir si le test a vraiment été exécuté. Une capture d'écran ne le prouve pas ; un journal d'exécution le prouve.
Article complet
Le rapport est livré, le client bloque sur un scénario et la même question arrive sur la table : « a-t-on vraiment essayé ? » S'il n'y a rien d'autre qu'une capture d'écran, la réponse repose sur la mémoire. Le testeur raconte ce qu'il a fait, le client n'est pas convaincu ; les deux ont raison, car aucun n'a de preuve.
Cet article explique comment ce débat disparaît. La réponse n'est pas davantage de captures ; c'est un journal de ce qui a été exécuté, dans quel environnement et quand, conservé sous une forme qu'on ne peut plus modifier ensuite.
Ce qu'une capture prouve, et ce qu'elle ne prouve pas
Une capture d'écran montre un instant : cet écran ressemblait à cela à ce moment-là. Elle ne dit pas sur quelle version, quel appareil ni après quelles étapes elle a été prise. Elle peut être recadrée, retouchée ou tirée d'une autre session. Elle est utile quand un bug est trouvé ; elle ne montre pas que les vingt scénarios sans bug ont vraiment été essayés.
Quatre questions auxquelles une preuve de test doit répondre
- Dans quel environnement le test a tourné : système, version, appareil, navigateur, firmware
- Quel scénario a commencé quand et s'est terminé quand
- Si les fichiers joints (journaux, enregistrement d'écran) ont changé ensuite
- Qui a écrit le journal et quand ; s'il peut être modifié
Le journal d'exécution : tenir trois choses à la fois
La solution consiste à retirer le journal des mains humaines. Un agent qui tourne sur la machine du testeur relève l'empreinte de l'environnement, écrit l'horodatage de début et de fin de chaque scénario et enregistre une empreinte (hash) de chaque fichier joint. Le testeur ajoute captures, journaux et étapes de reproduction ; le tout part en un seul paquet.
Le point critique est l'inaltérabilité. Si ni le testeur ni la plateforme ne peuvent modifier le journal ensuite, un rapport refusé se discute sur le journal, pas sur les souvenirs de chacun. La contestation regarde le même journal ; le testeur qui a raison est payé.
Indépendance : celui qui trouve et celui qui corrige ne doivent pas être la même partie
L'équipe qui écrit le produit ne peut pas le tester impartialement ; ce n'est pas un défaut, c'est la nature des choses. Le développeur sait comment le parcours doit fonctionner et le suit sans s'en rendre compte. L'utilisateur ne le sait pas et prend un autre chemin. Le test indépendant ne se réduit donc pas à « quelqu'un d'extérieur regarde » : quand la partie qui a trouvé le constat vérifie aussi le correctif, sans être celle qui l'a réalisé, la vérification est réellement indépendante.
Pourquoi le quota fait partie de la preuve
La concurrence invisible est la jumelle du travail invisible. Si le nombre de testeurs qu'une mission accepte est écrit d'avance, le testeur engage son temps en sachant contre combien il concourt ; quand le quota est plein, la mission quitte la liste. Si la rémunération est fixe d'avance et ne varie pas avec le nombre de bugs trouvés, une mission sans bug est payée quand même : ce qui est payé n'est pas le bug mais l'exécution des scénarios.
Résumé
Quatre conditions pour un test prouvé
- Une capture d'écran est une preuve de bug, pas de test
- Environnement, horodatages et empreintes de fichiers sont écrits par un agent et ne changent jamais
- Celui qui trouve, celui qui corrige et celui qui vérifie ne sont pas la même partie
- Quota et rémunération sont écrits d'avance ; les contestations se traitent sur le journal
Produits cités dans cet article
Du glossaire : Jeu d'évaluation (eval) · Décision validée par un humain (human-in-the-loop)