Enregistreur d’écran pour les rapports de bug : quoi filmer, et dans quel ordre

Comment enregistrer une vidéo de rapport de bug : l’ordre en 60 secondes

Reproduisez le bug une fois sans enregistrer pour connaître le chemin. Passez ensuite sur un compte de démo, fermez la messagerie et le mail pour qu’aucune notification n’apparaisse dans le cadre, puis enregistrez une seule prise continue dans cet ordre.

1. 0:00–0:05 · Contexte. Annoncez le build et l’environnement à voix haute : « Build 4.12.0, préprod, compte admin. »
2. 0:05–0:15 · État de départ. Montrez l’écran avant que quoi que ce soit ne se passe mal, avec l’URL ou le titre de la fenêtre.
3. 0:15–0:40 · Étapes. Faites chaque action à vitesse normale en la nommant : « Je saisis un nom, je choisis un rôle, je clique sur Enregistrer. »
4. 0:40–0:50 · Échec. Arrêtez de bouger le curseur et laissez le résultat erroné à l’écran pendant trois secondes.
5. 0:50–1:00 · Attendu. Dites en une phrase ce qui aurait dû se passer. Si le bug se reproduit à chaque fois, déclenchez-le une deuxième fois.

Modèle de rapport de bug à coller à côté de la vidéo

La vidéo est la preuve. Le texte du ticket, lui, est ce qu’on recherche, ce qu’on trie et ce qu’on relie au correctif. Copiez ces champs dans le ticket et remplissez chaque ligne.

• Titre : [écran ou fonctionnalité] + [action] + [résultat erroné]. Exemple : « Formulaire d’invitation : Enregistrer vide tous les champs quand le rôle est Lecteur. »
• Environnement : build de l’app, version du système, navigateur et sa version, type de compte ou rôle.
• État de départ : ce qui doit être vrai avant l’étape 1 (connecté en tant que…, feature flag…, enregistrement d’exemple…).
• Étapes pour reproduire : numérotées, une action par ligne.
• Résultat attendu : une phrase.
• Résultat constaté : une phrase, plus le texte exact de l’erreur s’il y en a un.
• Fréquence : à chaque fois, ou N tentatives sur 10.
• Vidéo : fichier ou lien, avec le timecode de l’échec (par exemple 0:42).
• Logs : sortie de la console ou identifiant de requête, collés en texte.

Exemple complet : un formulaire qui se vide à l’enregistrement

La situation : sur le build de préprod d’une app de gestion d’équipe, enregistrer une invitation avec le rôle Lecteur vide le formulaire et n’envoie rien. Avec le rôle Éditeur, tout fonctionne. La vidéo dure 48 secondes et l’échec se produit à 0:31. Voici le texte du ticket :

• Titre : Formulaire d’invitation : Enregistrer vide tous les champs quand le rôle est Lecteur.
• Environnement : build 4.12.0 (préprod), macOS 15.1, Chrome 129, administrateur de l’espace de travail.
• État de départ : connecté en tant que [email protected], Équipe → Membres ouvert, aucune invitation en attente.
• Étapes : 1. Cliquer sur Inviter un membre. 2. Saisir le nom « Camille Morel » et l’e-mail [email protected]. 3. Régler Rôle sur Lecteur. 4. Cliquer sur Enregistrer.
• Attendu : l’invitation apparaît dans En attente avec le rôle Lecteur.
• Constaté : le formulaire se vide, aucun toast n’apparaît et En attente reste à 0. Aucune erreur à l’écran.
• Fréquence : 5 fois sur 5 avec Lecteur, 0 fois sur 5 avec Éditeur.
• Vidéo : bug-invitation-lecteur.mp4, échec à 0:31. Deuxième reproduction à 0:40.
• Logs : POST /invites renvoie 422, « role: unsupported value ».

Vidéo, capture d’écran ou étapes écrites : que joindre au ticket

Choisissez le format selon ce que le développeur a besoin de voir. La plupart des bons rapports en combinent deux : des étapes écrites, plus une vidéo ou une capture d’écran.

Enregistrer les bugs audio et les échecs rares sur Mac avec Qreata

C’est sur les bugs audio qu’un enregistreur généraliste vous lâche. Imaginons que votre app joue deux fois le son de sa notification. Qreata capture toujours l’audio système avec l’écran, sur sa propre piste à côté de celle du micro : rien à activer, rien à oublier. Avant l’export, vous pouvez couper la piste du micro ou baisser son volume, pour que le développeur entende le son doublé sans votre clavier ni votre voix par-dessus.

Pour un bug qui n’apparaît qu’une fois par jour, la crainte est de perdre la prise. Qreata écrit l’enregistrement sur le disque par blocs de cinq secondes avec un journal de récupération : si la session est interrompue, la partie déjà enregistrée est restaurée à la prochaine ouverture de l’app. Avant de démarrer, « Active source check » affiche les images et l’audio en direct de chaque source.

Si le bug se trouve dans une petite fenêtre, choisissez « Window » comme cible de capture et non « Display », pour que le texte reste lisible dans le lecteur de l’outil de suivi. Après l’enregistrement, vous pouvez agrandir le curseur et mettre les clics en évidence, ce qui montre au développeur l’endroit exact où vous avez cliqué.

Ne touchez pas à l’échec lui-même. Si vous avez mal annoncé le build dans les cinq premières secondes, choisissez Replace Take (l’outil « Rerecord » de l’éditeur), faites glisser sur 0:00–0:06 dans la timeline en maintenant Maj enfoncée et réenregistrez uniquement cette phrase, en remplissant les six secondes entières. Les images du bug à 0:31 restent exactement telles qu’elles ont été capturées.

L’enregistrement reste sur votre Mac tant que vous n’appuyez pas sur un bouton d’envoi, et vous n’avez pas besoin de compte pour enregistrer. Un compte de démo reste le premier choix, mais certains bugs ne se reproduisent que sur un vrai compte. Dans ce cas, activez « Blur · select elements » avant la prise et cliquez sur les éléments à cacher, 8 au maximum, par exemple une colonne d’e-mails : le floutage les suit quand la page défile. Il demande l’autorisation « Accessibilité » de macOS et reste définitivement dans l’enregistrement. Pour ce que vous remarquez plus tard, l’outil « Blur » de l’éditeur recouvre un rectangle fixe sur un passage donné. Pour essayer, profitez de l’essai de 7 jours sur un bug que vous avez déjà signalé : enregistrez-le dans l’ordre ci-dessus et comparez le résultat avec votre rapport d’origine. Comptez une dizaine de minutes.

Les erreurs fréquentes qui font renvoyer une vidéo de bug

Voici pourquoi un développeur répond « impossible à reproduire » à un rapport accompagné d’une vidéo.

• Commencer en plein parcours. La vidéo s’ouvre sur l’erreur et personne ne sait comment vous y êtes arrivé.
• Couper les étapes. Supprimer les 20 secondes « ennuyeuses » avant l’échec, c’est supprimer la reproduction.
• Pas de numéro de build. Le bug est peut-être déjà corrigé dans un build plus récent.
• Un enregistrement de cinq minutes avec l’échec à 4:10 et aucun timecode dans le ticket.
• Rejouer un bug intermittent et présenter la reconstitution comme l’événement d’origine.
• Enregistrer tout l’écran en 4K alors que le bug est dans une petite fenêtre : le texte devient illisible dans le lecteur de l’outil de suivi.
• Une vidéo sans étapes écrites. Personne ne pourra la retrouver plus tard par la recherche.