Transformer un Enregistrement en Rapport sur Lequel Quelqu’un Peut Agir
Chargez l’enregistrement d’écran du bug. Lisez-le, et chaque fois que quelque chose d’important se produit, marquez-le. L’horodatage est capturé, une image est extraite de la vidéo à ce moment, et l’étape est ajoutée à une liste numérotée.
Écrivez le résumé, ce que vous attendiez et ce qui s’est passé à la place, puis copiez le tout au format Markdown pour GitHub, au format Jira ou en texte brut. Les détails du navigateur et de l’écran sont déjà remplis.
L’enregistrement ne quitte jamais votre machine. Il est lu à partir d’un fichier local et les images sont dessinées sur votre appareil, ce qui est important lorsque le bug se trouve dans une version non publiée ou sur le compte d’un client.
Pourquoi Ceci N’utilise Pas l’IA pour Rédiger le Rapport
Un modèle regardant un enregistrement d’écran peut décrire ce qu’il voit. Il ne peut pas savoir ce que vous vous attendiez à voir, et c’est la moitié d’un rapport de bug qui décide si quelqu’un peut agir dessus.
“Cliqué sur Confirmer, le panneau de facture était vide” est une observation. Que ce soit un bug dépend entièrement de ce qui aurait dû apparaître là, et la seule personne qui le sait, c’est vous. Un outil qui génère un comportement attendu à partir d’une vidéo fait des suppositions et présente la supposition comme une conclusion, ce qui est pire que de laisser le champ vide, car une fausse attente plausible envoie un développeur sur la mauvaise voie.
Donc, la séparation ici est délibérée. L’outil fait le travail mécanique qu’il peut faire exactement : horodatages, images, environnement, formatage, numérotation. Vous fournissez le jugement. Cela prend environ une minute et le résultat est un rapport pour lequel personne n’aura à revenir vers vous.
Les Trois Choses que les Rapports Manquent Habituellement
Ayant lu de nombreux rapports de bugs incomplets, les mêmes lacunes reviennent, et toutes les trois sont mécaniques plutôt que difficiles.
Horodatages. Un rapport qui dit “voir la vidéo ci-jointe” oblige le lecteur à regarder quatre minutes pour trouver le moment. Une étape qui dit que cela s’est passé à 1:12 ne le fait pas.
Environnement. Navigateur, système d’exploitation, taille de l’écran. Tout le monde sait qu’il faut l’inclure et presque personne ne le fait, car cela signifie ouvrir un panneau de paramètres alors que vous êtes en pleine réflexion. Il est lu depuis votre navigateur ici et se trouve déjà rempli dans le rapport, et vous pouvez le corriger.
Images fixes. Une image au moment de l’échec est ce qui est scanné dans une liste de vingt problèmes. Extraire des images d’une vidéo à la main est suffisamment fastidieux pour que les gens l’ignorent, donc cela se produit automatiquement à chaque étape que vous marquez.
Ce qui Est Capturé, Précisément
Chaque étape marquée enregistre l’heure de lecture exacte et une image JPEG de la vidéo à ce moment-là, redimensionnée pour garder le rapport léger. Vous pouvez télécharger les images pour les joindre au problème.
L’environnement provient du navigateur : son nom et sa version, le système d’exploitation, la taille de l’écran avec son ratio de pixels, et la taille de la fenêtre d’affichage. Les navigateurs signalent maintenant moins d’informations sur eux-mêmes qu’auparavant, de sorte que certains de ces champs peuvent revenir inconnus, et chaque champ est modifiable plutôt que verrouillé.
Rien n’est déduit des pixels. L’outil n’essaie pas de lire le texte d’erreur à l’écran ni de deviner quel élément vous avez cliqué, car le faire de manière peu fiable est pire que de ne pas le faire.
La Structure qu’il Remplit
Le résultat suit la forme qu’un rapport de bug a adoptée, car les outils de suivi et les personnes qui les lisent s’y attendent. Si vous cherchiez un modèle de rapport de bug, en voici un qui arrive déjà rempli plutôt qu’un que vous collez et fixez.
Résumé d’abord, en une seule ligne, car cette ligne est ce que quelqu’un parcourt dans une liste de trente problèmes et elle décide si le vôtre sera ouvert aujourd’hui.
Ensuite, des étapes numérotées avec le code temporel pour chacune, le comportement attendu, le comportement réel et l’environnement. Cet ordre n’est pas une décoration. Un lecteur vérifie les étapes pour voir si le problème est reproductible, la paire attendu/réel pour voir s’il s’agit réellement d’un bug, et l’environnement pour voir si cela les concerne. Oublier l’un de ces éléments coûte un aller-retour.
Ce qu’un modèle vierge ne peut pas faire, c’est se remplir, ce qui est la raison pour laquelle les gens le zappent. Ici, les étapes, les codes temporels, les images et l’environnement arrivent renseignés, et vous écrivez les trois champs qu’un outil ne peut vraiment pas connaître.
Avant d’enregistrer
Le rapport n’est bon que si l’enregistrement l’est, et deux habitudes font la différence.
Commencez à partir d’un état connu. Un enregistrement qui commence au milieu d’une session laisse le lecteur deviner ce qui s’est passé avant, de sorte que les étapes ne sont plus reproductibles. Commencez à partir d’un écran de connexion, d’une nouvelle page ou d’un point de départ décrit.
Nettoyez l’écran de tout ce qui ne doit pas être transféré. Jetons dans une barre d’URL, nom d’un client, e-mail sans rapport dans un autre onglet, clé API dans un panneau d’outils de développement. Un rapport de bogue est transféré, collé dans un chat et lu par des personnes extérieures à l’équipe, et un enregistrement d’écran contient tout ce qui était affiché à ce moment-là. Cet outil ne télécharge jamais la vidéo, mais le rapport et les images vont où vous les envoyez.
Ce qu’il ne fait pas
Il ne dépose pas le problème. Il n’y a pas de connexion à GitHub, Jira ou quoi que ce soit d’autre ; vous copiez le rapport et le collez là où il doit être, ce qui signifie aussi que vous pouvez le lire avant tout le monde.
Il ne capture pas les journaux, les requêtes réseau ou la sortie de la console. Ceux-ci résident dans vos outils de développement et sont extrêmement importants pour certains bogues. Joignez-les via la route sécurisée que votre équipe utilise déjà plutôt que de filmer une console.
Et il ne diagnostique rien. Il ne vous dira pas la cause, quel composant est en faute, ou si cela duplique un problème existant. Il met les preuves sous une forme à partir de laquelle quelqu’un peut travailler, et c’est tout son travail.
Enregistrer le bogue en premier lieu
Si vous avez encore besoin de capturer le problème, l’enregistreur d’écran enregistre un onglet, une fenêtre ou l’affichage entier dans le navigateur. Pour un bogue que vous devez narrer pendant que vous le reproduisez, enregistrez avec de l’audio et l’explication reste attachée aux preuves.
Deux outils utiles à connaître. Si vous voulez des images uniques plutôt qu’un rapport, l’extracteur d’images vidéo extrait des images à intervalles réguliers. Et si l’enregistrement est long et que vous voulez la narration orale sous forme de texte, le générateur de transcriptions transforme la narration en quelque chose de consultable.
