Comment obtenir un rapport de bug utilisable d'une personne non technique

Quelqu’un qui n’est pas technique n’est pas un mauvais signataire. Il répond à une question différente de celle que vous aviez posée, et généralement, c’est la question qui était le problème.

Presque chaque formulaire de signalement de bug demande trois choses : ce qui s’est mal passé, comment le reproduire, et ce que vous attendiez à la place. Chacune de ces questions demande au signataire de faire un diagnostic. « Qu’est-ce qui s’est mal passé » demande une cause. « Attendu versus réel » demande de savoir ce que le logiciel aurait dû faire, une connaissance qu’il n’a pas et qui explique pourquoi il vous contacte. « Comment reproduire » demande d’avoir remarqué une séquence qui n’avait pas d’importance avant qu’elle échoue.

Ce qu’une personne peut vous donner avec précision, c’est ce qu’elle essayait de faire et ce qu’elle a vu. Ce sont des observations. Le reste du formulaire demande généralement une théorie.

La théorie est ce qu’il faut laisser de côté

Le coût d’un rapport inexpérimenté n’est pas le détail manquant. C’est l’explication, car une explication ressemble à une observation et vous passerez la matinée dedans.

« Le site m’a déconnecté » est une conclusion. Dessous, ce qui s’est réellement passé est qu’un écran est apparu avec un formulaire de connexion. Cet écran a au moins quatre causes qui n’ont rien à voir les unes avec les autres : la session a réellement expiré, un appel API a retourné un 401 et le client a redirigé, une page en cache a été servie avec l’en-tête déconnecté, ou il avait un second onglet ouvert et s’était déconnecté dedans. Partez de « déconnecté » et vous allez au magasin de session. Partez de « un écran de connexion s’est affiché alors que j’étais au milieu du paiement » et vous avez le timing, la page, le symptôme, et le magasin de session est une place parmi quatre où chercher plutôt que la seule.

Faible

Le site m'a déconnecté pendant que je payais.

Mieux

J'étais à l'étape de paiement et la page a repris le formulaire de connexion. Mon panier était toujours là après.

Rien dans la version meilleure ne demande de connaissance technique. C’est la même personne, à qui on demande ce qu’elle a vu au lieu de ce que cela signifiait.

Les mots qui ne signifient pas ce que vous supposez

Le vocabulaire est partagé et les définitions ne le sont pas. Ces cinq termes font le plus de dégâts car les deux côtés sont sûrs d’avoir bien compris.

Planté

L'onglet s'est fermé, la page est devenue blanche, un spinner ne s'est jamais arrêté, ou le navigateur lui-même a fermé.

Gelé

Rien ne répondait aux clics, ou quelque chose était en train de charger sans indiquer que c'était le cas.

Supprimé

Il a disparu de la liste devant eux. Il peut être filtré, sur une autre page, dans un autre compte, ou réellement supprimé.

Page

Une URL, un onglet, une fenêtre modale, une étape dans un flux, ou tout le site.

Erreur

Un message que vous avez écrit, un écran d'erreur du navigateur, ou simplement un résultat qu'ils ne voulaient pas.

Vous ne pouvez pas corriger cela en publiant un glossaire, car personne ne le lira avant de signaler un problème. Vous le corrigez en ne posant jamais une question dont la réponse est un de ces mots. « Est-ce qu’il a planté » n’a pas de réponse utile. « Qu’est-ce qui était sur l’écran quand ça a arrêté de fonctionner » en a une.

Demandez le dernier truc qui fonctionnait

La question la plus productive à poser à quelqu’un sans le vocabulaire n’est pas du tout sur l’échec.

Demandez ce qu’il faisait immédiatement avant, et demandez si cela a déjà fonctionné. Les deux sont des choses qu’une personne se souvient sans effort, et ensemble elles délimitent le problème : la première vous donne le point d’entrée, et la deuxième vous dit si vous regardez une régression ou quelque chose qui n’a jamais fonctionné pour cette personne dans cette situation. Une fonctionnalité qui a fonctionné pour eux mardi dernier et pas aujourd’hui est une investigation différente de celle qui n’a jamais fonctionné une seule fois.

« Cela a-t-il déjà fonctionné pour vous » fait aussi quelque chose que les autres questions ne font pas. C’est répondable par oui ou non, donc c’est presque toujours répondu.

Demandez l’écran, pas une description

Une capture d’écran est l’unique artefact que quelqu’un sans expérience produit à la fois de manière fiable et précise, car en prendre une n’a besoin d’aucun vocabulaire. Elle contient des choses qu’ils n’auraient pas pu vous dire si vous aviez demandé : l’URL dans la barre d’adresse, la largeur de la fenêtre, le compte qui est connecté, le libellé exact du message, si une bannière couvrait le bouton. La plupart de ce que vous auriez extrait en quatre e-mails se trouve dans une image qui leur a pris cinq secondes.

Donc « pourriez-vous m’envoyer une photo de ce que vous voyez » vaut plus que n’importe quelle question que vous pourriez écrire, et c’est la chose la plus facile de la liste à demander.

La limite vaut la peine d’être connue aussi. Une capture d’écran montre la surface à un moment. Elle ne peut pas dire ce que le navigateur faisait dessous, et l’échec laisse souvent aucune marque sur la surface du tout : une requête qui a retourné un 500 alors que la page avait l’air normale est invisible dans une image.

Ce qu’ils ne peuvent pas vous donner, et ne devraient pas être demandés

Erreurs de console, journal réseau, version du navigateur, taille de fenêtre. Ce sont les choses qui raccourciraient réellement l’investigation, et chacune demande au signataire d’ouvrir un outil de développeur et de savoir ce qu’il cherche.

Demander cela a un vrai coût et ce n’est pas le temps du signataire. C’est que la demande se lit comme un test. Quelqu’un qui ne peut pas trouver la console maintenant sait qu’il n’a pas bien aidé, et la prochaine chose qu’il remarque, il la garde pour lui. Le nombre de personnes disposées à vous dire qu’il y a un problème est petit et entièrement volontaire, et il est plus facile à perdre qu’à construire.

L’honnête réponse est que cette moitié devrait être collectée plutôt que demandée.

Il n’écrira pas le titre pour vous, et il ne peut pas dire ce que la personne essayait de faire. Cette partie ne vient qu’en leur demandant, c’est pourquoi les questions importent.

Posez une à la fois

Une liste de six questions revient avec deux réponses et aucune indication sur les quatre qui ont été ignorées. Pire, cela se lit comme un formulaire, et un formulaire est une chose que les gens remettent à plus tard jusqu’au week-end.

Envoyez une question. Quand elle est répondue, envoyez la suivante si vous en avez toujours besoin. Cela semble plus lent et ce n’est pas le cas, car l’alternative est un long silence suivi d’une réponse partielle qui génère trois autres questions de toute façon.

Gardez à l’esprit ce que vous interrompez. Un rapport de bug est la fin d’une chaîne de petites décisions à déranger : ils ont remarqué, ils ont décidé que ce n’était pas leur faute, ils ont découvert où vous dire, et ils l’ont écrit. Chaque échange après cela est une autre chance que la chaîne se brise, et rien ne vous dit quand c’est le cas. Vous n’entendez jamais parler à nouveau, ce qui de votre côté est indiscernable du problème ayant disparu.

Les questions, dans l’ordre où les poser

Quatre questions, dont aucune ne demande à la personne de savoir quoi que ce soit sur le logiciel :

• Qu’essayiez-vous de faire ?
• Qu’avez-vous vu à la place ? Si possible, envoyez une photo.
• Quand était-ce environ, et qu’utilisiez-vous à ce moment-là ?
• A-t-il jamais fonctionné pour vous avant ?

Si vous obtenez ces quatre, vous avez le point d’entrée, le symptôme, une fenêtre pour chercher dans vos journaux, et si c’est une régression. C’est suffisant pour commencer, et c’est plus que la plupart des tickets écrits par des gens qui connaissent le vocabulaire.