Une recette (les tests d'acceptation utilisateur, ou UAT) a une forme reconnaissable. Vous donnez à un groupe de personnes (des collègues, l'équipe d'un client, une poignée de clients bêta) l'accès à un build et une semaine pour l'essayer. À la fin, vous recevez un tableur.
Le tableur compte soixante lignes. Une quinzaine sont exploitables tout de suite. Vingt décrivent les trois mêmes bugs de cinq façons différentes. Dix relèvent du comportement voulu. Dix demandent une question de suivi avant que quiconque puisse commencer. Et cinq disent quelque chose comme « j'ai voulu enregistrer et ça n'a pas marché », sans indiquer la page, le navigateur ni le jour.
Le premier réflexe est d'accuser la formation. Écrire un meilleur modèle, organiser une session sur la façon de bien signaler un bug, exiger des étapes de reproduction. Ça aide un peu, et l'effet s'estompe en quinze jours.
S'il s'estompe, c'est pour une raison structurelle. Les testeurs de recette ne sont pas des ingénieurs QA, et leur demander de se comporter comme tels, c'est demander quelque chose que le dispositif ne permet pas.
Pourquoi les testeurs signalent trop peu
Trois contraintes, et aucune n'est une question d'effort.
Ils ne voient pas les preuves. Un testeur de recette n'a pas les DevTools ouverts. Il ne sait pas qu'une requête a renvoyé une 500. Il voit un spinner qui ne s'arrête jamais et note « ça s'est figé ». L'information qui aurait résolu le bug en quatre-vingt-dix secondes était sur son écran, derrière un raccourci clavier que personne ne lui a montré.
Signaler coûte plus cher que le bug ne semble valoir. Un testeur qui doit passer sur un tableur, trouver les bonnes colonnes, décrire le contexte et prendre une capture d'écran le fera pour un plantage. Pour le libellé mal aligné et le message d'erreur déroutant, il le notera mentalement et passera à autre chose. Ce sont précisément les remarques pour lesquelles vous avez organisé une recette.
Ils testent, ils ne documentent pas. Un testeur concentré explore un parcours. Chaque interruption pour écrire un rapport casse cet élan, alors les rapports sont regroupés en fin de session, c'est-à-dire au moment où les détails sont les plus lointains et où la reproduction a déjà été écrasée par vingt actions suivantes.
Chacune de ces contraintes tient au canal de signalement, pas à la personne. Changez le canal, et le comportement change.
Placer le signalement dans ce qu'on teste
Le changement qui a le plus d'effet consiste à déplacer le signalement d'un outil séparé vers l'application testée elle-même.
Un bouton de signalement sur la page fait tomber les trois contraintes d'un coup. Il n'y a plus de changement de contexte, donc les rapports sont envoyés au moment de la découverte au lieu d'être regroupés à la fin. Le coût tombe à un clic, donc les petites remarques sont signalées. Et le navigateur est là, donc les preuves sont jointes sans que le testeur sache ce qu'est une preuve.
C'est ce que fait un outil à base de widget. BugDump s'installe avec une seule balise script sur le build de staging :
<script src="https://bugdump.com/sdk/latest.js" data-api-key="your-api-key"></script>Le testeur clique, tape « j'ai voulu enregistrer et ça n'a pas marché » et envoie. Ce qui arrive, c'est cette phrase accompagnée du log de la console, y compris tout ce qui a été loggé avant l'ouverture du widget, des requêtes réseau avec leurs statuts et leurs durées, d'une relecture de session, de ses clics et saisies dans l'ordre, et de son navigateur, son OS, son viewport et son URL.
Le testeur n'est pas devenu meilleur pour signaler des bugs. Le canal a simplement cessé de jeter les preuves.
La configuration pour une recette
Quelques choix de configuration comptent davantage en test qu'en production.
Identifiez vos testeurs. En production, vous ne savez pas toujours qui signale. En recette, vous le savez toujours, et ça vaut la peine de le brancher : appelez identify() avec le nom et l'e-mail du testeur, et setContext() avec son rôle, son compte de test et le scénario qui lui a été confié. Quand quatre rapports arrivent sur des problèmes de permissions, voir que les quatre viennent de testeurs en lecture seule, c'est le diagnostic.
Joignez le build. Mettez le hash du commit ou le numéro de build dans le contexte. Une recette couvre généralement plusieurs déploiements, et sans cette information, impossible de répondre à « est-ce que c'est toujours cassé après le correctif de mardi ? ».
Rendez le bouton impossible à rater. En production, un bouton flottant discret convient. En recette, non : utilisez la bulle d'accroche avec un texte qui dit ce que vous attendez, quelque chose de plus proche de « Vous avez trouvé quelque chose ? Dites-le-nous » que d'une icône muette. Les testeurs qui oublient que l'outil existe envoient leurs rapports par e-mail.
Activez les corps réseau, en connaissance de cause. Les corps de requête et de réponse sont ce que vous pouvez joindre de plus utile, et de plus sensible. Sur un environnement de staging avec des données synthétiques, activer captureNetworkBodies va généralement de soi, et supprime toute une catégorie de questions de suivi. Pour une recette sur des données de production avec de vrais dossiers clients, non : laissez-le désactivé, ou filtrez les endpoints qui transportent des données personnelles.
Filtrez le bruit. Les environnements de staging sont bruyants. Un networkFilter qui écarte les endpoints de polling et un consoleFilter qui écarte le bavardage de niveau debug rendent les rapports bien plus lisibles, et un rapport lisible est trié au lieu d'être remis à plus tard.
Demander trois choses, pas douze
Comme la capture est automatique, le formulaire ne doit demander que ce que seul le testeur sait :
Ce qui n'a pas marché, avec ses mots
Ce qu'il attendait à la place
À quelle fréquence : la première fois, parfois, à chaque fois
Tout le reste (navigateur, OS, URL, console, réseau, chronologie) arrive tout seul.
Cette troisième question mérite d'être défendue contre l'envie de la supprimer. « À chaque fois » ou « parfois », c'est la différence entre un bug déterministe et une race condition, et ça change l'endroit où un développeur va chercher avant même qu'il ait commencé. C'est aussi la seule information sur la fréquence qu'aucune instrumentation ne peut fournir, parce qu'elle n'existe que dans les souvenirs que le testeur garde des vingt dernières minutes.
Résistez à l'envie d'ajouter une liste déroulante de gravité. Chaque testeur choisit « Haute », parce que, de l'intérieur d'un scénario de test bloqué, tout est grave. La fréquence, plus le nombre de personnes qui signalent le problème, fait le même travail avec de meilleures données.
Les doublons, c'est tout l'intérêt
Le réflexe habituel, en recette, est de voir les doublons comme du gaspillage : vingt lignes pour trois bugs. C'est l'inverse.
Cinq personnes qui signalent le même bouton d'enregistrement cassé, ce sont cinq environnements, cinq séquences d'étapes, cinq journaux réseau. Si quatre sont sur Safari et une sur Chrome avec un viewport étroit, vous tenez la cause avant que quiconque ouvre le code. Un seul rapport sur ce bug vous en aurait appris bien moins.
Il ne vous faut pas moins de doublons. Il vous faut une structure où ils s'empilent au lieu de s'éparpiller. C'est précisément pour ça que BugDump sépare les rapports des tâches : un rapport, ce sont les preuves d'une personne ; une tâche, c'est ce que vous corrigez vraiment, et plusieurs rapports se rattachent à une même tâche. Vingt rapports deviennent six tâches, chacune avec toutes ses preuves, et les vingt lignes cessent d'être du fouillis pour devenir une matrice.
Les testeurs peuvent rattacher leur rapport à une tâche existante grâce à son identifiant public si vous activez allowTaskAttach. « Quelqu'un l'a sûrement déjà signalé » cesse alors d'être une raison de ne rien envoyer et devient une confirmation en un clic que le problème les touche aussi.
Bouclez la boucle, ou la recette meurt
Le moyen le plus sûr de tuer la participation à une recette, c'est le silence. Un testeur qui envoie six rapports la première semaine sans aucun retour n'en envoie aucun la deuxième. Pas par dépit : il a simplement appris que signaler ne sert à rien, et il a raison.
Deux choses règlent ça, et elles ne coûtent presque rien.
Envoyez les rapports là où l'équipe se trouve déjà. Un canal Telegram, Slack ou Discord qui reçoit un message par rapport rend la recette vivante pour tout le monde, testeurs compris. Si les bugs doivent devenir des issues, une intégration GitHub Issues ou Jira évite que quelqu'un recopie le tableur dans un outil de suivi.
Donnez aux testeurs une page de suivi. Un portail public où l'auteur d'un rapport voit sa tâche passer de Confirmé à Terminé, c'est tout le mécanisme. Quelqu'un qui voit son rapport corrigé envoie le suivant, et il l'envoie en troisième semaine, quand les bugs intéressants apparaissent.
À quoi ça ressemble à la fin de la recette
Le tableur est remplacé par un tableau kanban. Soixante rapports se sont réduits à deux douzaines de tâches, chacune avec les preuves de tous ceux qui sont tombés dessus. Les lignes inexploitables ont disparu, parce que les champs qui les rendaient inexploitables ont été remplis par le navigateur et non par une personne qui devinait ce qui comptait.
Le travail du testeur redevient ce qu'il aurait toujours dû être : utiliser le logiciel et dire ce qui semblait clocher. Comprendre ce que ça signifie, c'est le travail du développeur, et il a maintenant de quoi le faire.
Le forfait Gratuit de BugDump couvre 500 rapports par projet et par mois, sans carte bancaire, ce qui suffit largement pour la plupart des recettes : installez-le sur le build de staging la veille du début des tests.
Pour aller plus loin
Collecter les rapports de bug des bêta-testeurs sans en perdre la moitié — un widget dans la bêta, le contexte capturé automatiquement et des testeurs tenus au courant.
De 40 rapports à 6 bugs – comment le tri devrait fonctionner — pourquoi BugDump sépare les rapports des tâches, et pourquoi les doublons aident à déboguer.
Comment une agence web collecte les rapports de bug de ses clients — un widget sur chaque site client, un tableau par projet et une passation propre en fin de mission.