Quelqu’un sur votre site tombe sur un bug. Cette personne le voit : la mise en page cassée, le bouton qui ne fait rien, le message d’erreur en rouge. Le temps que cela parvienne à un développeur, c’est devenu une phrase. “Le paiement est cassé.” Tout ce qu’il y avait à voir a été jeté, et le premier travail du développeur consiste à le reconstituer en posant des questions.
Le rapport de bug visuel est la pratique qui consiste à capturer ce qui était à l’écran, et ce que le navigateur savait, au moment où quelqu’un a décidé de signaler un problème. Le rapport est la preuve plutôt qu’une description de celle-ci.
Ce qu’il contient vraiment
Le mot “visuel” est réducteur. L’image est la partie que l’on remarque ; l’essentiel de la valeur tient à ce que le navigateur faisait derrière l’image.
Un rapport de bug visuel contient généralement une partie ou la totalité de ceci :
- Une capture d’écran ou un enregistrement de la page telle que l’auteur du signalement l’a vue, souvent avec quelque chose dessiné dessus pour pointer le problème.
- L’environnement : navigateur et version, système d’exploitation, taille de l’écran. Les faits qui décident si un défaut est universel ou appartient à une seule configuration.
- La sortie de la console, y compris l’erreur qui s’est affichée pendant que personne ne regardait la console.
- Le journal réseau : quelles requêtes la page a faites, ce qui est revenu, combien de temps cela a pris. Fréquemment la réponse est un 403 que personne n’a vu.
- Ce que l’auteur du signalement a fait : les clics, les saisies dans les formulaires et les changements de page qui y ont mené, dans l’ordre.
C’est ce dernier point qui transforme un rapport en instructions. Des étapes de reproduction écrites de mémoire sont une reconstitution ; une séquence enregistrée est un relevé.
En quoi il diffère du session replay
Les deux sont confondus, y compris par nous : notre produit s’appelle Session Replay, un nom que nous avons choisi et une catégorie dans laquelle nous ne sommes pas.
Le session replay, au sens habituel du terme, est une pratique d’analytique. Un script tourne sur chaque page pour chaque visiteur et enregistre les sessions en continu pour que quelqu’un puisse les regarder plus tard, en général à la recherche de tendances : où les gens hésitent, où ils abandonnent un formulaire, quel rage click précède quel départ. Personne n’appuie sur quoi que ce soit. L’enregistrement existe parce que tout le monde est enregistré.
Le rapport de bug visuel commence quand une personne décide que quelque chose ne va pas. Rien n’est enregistré avant qu’elle n’agisse, et ce qu’elle produit s’adresse à un lecteur précis avec un défaut précis en tête.
- Session replay
- Toujours actif, tous les visiteurs, regardé après coup pour trouver des problèmes que personne n'a signalés
- Rapport de bug visuel
- Commence quand quelqu'un signale, capture un incident, part vers celui qui peut le corriger
La différence compte pour deux raisons pratiques. La première est la vie privée : un outil qui enregistre tout le monde par défaut doit répondre de ce qu’il a stocké sur des gens qui n’ont jamais rien demandé, et c’est pourquoi les outils de session replay consacrent une si grande part de leur documentation au masquage. Un rapport qui n’existe que parce que quelqu’un a choisi de le déposer a une question bien plus petite à laquelle répondre.
La seconde est la recherche. Retrouver, parmi des milliers, la seule session qui contient le bug dont on vous a parlé est un travail en soi. Un rapport arrive en sachant déjà de quel incident il s’agit.
Là où c’est le mauvais outil
Le rapport de bug visuel ne voit que ce que quelqu’un a choisi de signaler. Il ne vous dira pas combien d’autres personnes ont rencontré le même défaut et sont parties, et il ne fera pas apparaître un problème dont personne ne s’est plaint. C’est l’analytique qui répond à cela, et un rapport de bug ne le peut pas.
Il est tout aussi inutile pour tout ce que le navigateur ne peut pas voir. Un job qui a échoué dans une file, un import nocturne qui a écrit les mauvaises lignes, une course entre deux services : rien de tout cela n’est sur une page, et aucune quantité de capture d’écran ne le trouvera. C’est à cela que servent les logs et le tracing.
La position honnête est qu’il s’agit de trois outils pour trois questions différentes. Ce qui s’est mal passé pour cette personne, à cet instant, est la seule à laquelle un rapport de bug visuel réponde bien.
À quoi cela ressemble en pratique
La version que nous construisons est une extension Chrome. Quelqu’un tombe sur un bug, clique sur l’icône et obtient une capture d’écran ou un enregistrement auquel sont joints l’environnement, la sortie de la console, le journal réseau et la séquence de ce qu’il a fait. Il reçoit un lien à coller là où le travail est suivi. Aucun compte n’est nécessaire pour en déposer un.
Session Replay
Extension Chrome gratuite. Un clic sur la page qui se comporte mal capture la capture d'écran, la console et le journal réseau, et vous donne un lien à coller dans le ticket.
Deux choses qu’elle ne fait pas, puisqu’une explication de catégorie qui ne liste que des atouts est une publicité. Elle ne surveille pas tout le monde : rien n’est enregistré avant que quelqu’un décide de signaler quelque chose, elle ne vous parlera donc jamais des gens qui ont rencontré le même défaut et sont partis sans rien dire. Et elle ne décide pas de ce qui compte. Le titre, la gravité et le jugement sur le fait de savoir si deux symptômes sont un seul défaut restent à la personne qui était là, ce qui est le sujet de comment écrire un rapport de bug parfait.
Si vous hésitez entre les deux
Demandez-vous à quelle question vous cherchez à répondre.
Si c’est “pourquoi les gens abandonnent-ils ce formulaire”, vous voulez de l’analytique, et le session replay fait partie de cette famille. Si c’est “pourquoi cela a-t-il cassé pour cette personne”, vous voulez l’incident capturé et envoyé à quelqu’un, et c’est du rapport de bug. Les équipes qui ont besoin des deux utilisent en général les deux, et confondre l’un avec l’autre est la façon de finir par regarder quatre cents enregistrements pour en trouver un que quelqu’un aurait pu vous tendre en quinze secondes.
Les rapports eux-mêmes doivent toujours être bien écrits : la capture supprime l’excuse d’un contexte manquant, pas le besoin d’un titre clair et d’un compte rendu honnête de ce que vous attendiez. Les dix erreurs les plus courantes restent à la portée de quiconque signale, même avec le meilleur outillage du monde.