Générateur de rapports de bugs.

Transformez un enregistrement en un rapport directement exploitable

Chargez l’enregistrement d’écran du bug. Lancez la lecture et, chaque fois qu’un événement important se produit, marquez-le. L’horodatage est capturé, une image de la vidéo est extraite à cet instant précis, et l’étape s’ajoute à une liste numérotée.

Rédigez le résumé, le comportement attendu et ce qui s’est réellement passé, puis copiez l’ensemble au format Markdown pour GitHub, balisage Jira ou texte brut. Les détails relatifs au navigateur et à l’écran sont déjà renseignés.

L’enregistrement ne quitte jamais votre appareil. Il est lu à partir d’un fichier local et les images sont générées sur votre machine, un atout précieux lorsque le bug concerne une version non publiée ou 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

La qualité d’un rapport dépend entièrement de celle de l’enregistrement, et deux habitudes font toute la différence.

Partez d’un état connu. Un enregistrement qui commence en plein milieu d’une session oblige le lecteur à deviner ce qui s’est passé avant, rendant les étapes impossibles à reproduire. Commencez par un écran de connexion, une nouvelle page ou un point de départ clairement défini.

Nettoyez l’écran de tout élément confidentiel. Des jetons dans la barre d’adresse, le nom d’un client, un e-mail sans rapport dans un autre onglet, une clé d’API dans la console développeur. Un rapport de bug est souvent transféré, collé dans un chat et lu par des personnes externes à l’équipe, et un enregistrement d’écran capture tout ce qui était visible à ce moment-là. Cet outil ne téléverse jamais la vidéo, mais le rapport et les images iront là où vous les enverrez.

Ce que l’outil ne fait pas

Il ne crée pas le ticket. Il n’y a aucune connexion à GitHub, Jira ou tout autre outil ; vous copiez le rapport et le collez là où vous le souhaitez, ce qui vous permet également de le relire avant tout le monde.

Il ne capture ni les journaux d’événements, ni les requêtes réseau, ni la sortie de la console. Ces éléments se trouvent dans vos outils de développement et sont cruciaux pour certains bugs. Joignez-les via les canaux sécurisés déjà utilisés par votre équipe plutôt que de filmer une console.

Et il ne pose aucun diagnostic. Il ne vous indiquera pas la cause, quel composant est défaillant, ni s’il s’agit d’un doublon d’un problème existant. Il structure les preuves pour que quelqu’un puisse travailler dessus, et c’est là toute sa mission.

Enregistrer le bug dès le départ

Si vous devez encore capturer le problème, l’enregistreur d’écran capture un onglet, une fenêtre ou l’écran entier directement dans le navigateur. Pour un bug que vous devez commenter tout en le reproduisant, enregistrez avec le son afin que l’explication reste associée aux preuves.

Deux outils complémentaires à connaître : si vous préférez des images isolées 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 souhaitez obtenir les explications orales sous forme de texte, le générateur de transcription transforme la narration en un contenu consultable.

Interroger l’enregistrement sur le bug

L’analyse sur cette page s’exécute sur votre appareil et ne nécessite aucun compte. Pour obtenir des réponses sur ce qui a été dit ou montré dans l’enregistrement, téléversez-le sur ScreenApp. Cliquez sur une question pour ouvrir ScreenApp avec la requête prête à être envoyée.

Dans ScreenApp, Cliquer sur un moment dans la transcription fait sauter le lecteur à ce point de l'enregistrement, ce qui vous permet de vérifier n’importe quelle réponse directement par rapport à l’enregistrement.

Ce que propose chaque forfait ici

L’outil sur cette page est gratuit et le restera. Un compte sert pour l’étape précédente ou l’étape suivante.