Comment reproduire un bug, et que faire de ceux que vous ne pouvez pas reproduire

“Cannot reproduce” [impossible à reproduire] est la façon la plus courante dont meurt un rapport de bug, et cette expression mérite d’être lue attentivement, car elle ne dit pas ce que l’on croit qu’elle dit. Ce n’est pas une affirmation sur le bug. C’est une affirmation sur deux environnements : le leur, où cela s’est produit, et le vôtre, où cela ne s’est pas produit.

Le bug lui-même n’est pas en cause. Quelqu’un l’a vu se produire. Ce qui est en cause, c’est votre capacité à reconstruire les conditions nécessaires, et la plupart du temps le rapport ne les contient pas, car la personne qui l’a rédigé n’avait aucune idée de laquelle, parmi les mille choses qui l’entouraient, avait de l’importance.

Ce dont une reproduction a vraiment besoin

Les étapes ne sont qu’un élément parmi quatre, et c’est celui auquel tout le monde pense.

Les mêmes étapes. Ce qu’ils ont cliqué, dans l’ordre, en partant d’un point où vous pouvez vous aussi commencer.

Le même état. Le compte, les permissions, les feature flags, les paramètres modifiés il y a dix-huit mois, le brouillon à moitié terminé qui traîne dans la base de données. C’est celui qui fait échouer le plus de tentatives, car l’état est invisible à la personne qui s’y trouve. Elle ne sait pas que son compte est particulier. C’est juste son compte.

Les mêmes données. Pas un enregistrement de test tout neuf, mais celui-là précisément : la commande avec un remboursement, le nom avec une apostrophe, la liste vide, le fichier envoyé de quarante mégaoctets. Les données de test sont propres. Les données de production sont quinze ans de décisions accumulées, ce qui est le même écart qui rend le staging mensonger.

Le même environnement. Navigateur et build, appareil, réseau, taille d’écran, horloge, extensions. Une version à elle seule peut suffire : “la dernière version de Chrome” a désigné trois versions majeures différentes en une semaine.

Quatre axes, et un rapport n’en fixe généralement qu’un seul. Le travail de reproduction consiste à deviner les trois autres, ce qui explique pourquoi cela prend une après-midi et pourquoi cela se termine si souvent par un haussement d’épaules.

Partez de l’état, pas des étapes

Le réflexe naturel est de suivre les étapes et de voir ce qui se passe. Le meilleur premier geste consiste à se demander ce qui devrait être vrai pour que ces étapes échouent.

Si le paiement échoue à l’étape du règlement, les étapes se résument à trois clics que n’importe qui peut faire. Ce qui n’est pas universel, c’est le panier, l’adresse, le moyen de paiement, la devise, le fait que ce compte ait déjà été remboursé ou non. Déterminez lesquels de ces éléments pourraient changer le résultat, et vous aurez transformé un rapport vague en trois ou quatre expériences précises.

Faible

Étapes suivies sur un compte de test. Ça fonctionne. Fermé comme "cannot reproduce".

Meilleur

Les étapes fonctionnent sur un compte neuf. Le compte du rapporteur a une carte enregistrée dans une devise que nous ne prenons plus en charge, et l'échec se situe dans la recherche de devise. Reproduit en ajoutant une telle carte sur un compte de test.

La seconde version ne demande pas plus d’effort. C’est le même effort, dirigé vers la bonne question.

Réduisez la reproduction jusqu’au plus petit cas qui échoue encore

Une fois que l’échec est fiable, retirez des éléments un par un. Supprimez une étape, supprimez un champ, utilisez un fichier plus petit, désactivez une extension, réduisez les données. Chaque suppression, soit maintient l’échec, auquel cas cet élément n’était pas nécessaire, soit le fait disparaître, auquel cas vous venez de trouver quelque chose d’important.

Cela vaut la peine même quand vous avez déjà le correctif, pour deux raisons. Une reproduction minimale devient un cas de test que quelqu’un pourra conserver. Et le fait de minimiser révèle très souvent la cause avant même d’avoir regardé une ligne de code : le bug qui ne survit que lorsque la liste est vide est en train de vous dire ce qu’il est.

Méfiez-vous de la reproduction qui ne fonctionne que de temps en temps. Ce n’est pas une reproduction ratée, c’est un bug d’une autre nature, et l’intermittence est une donnée, pas du bruit : quelque chose entre en compétition, ou dépend d’un ordre, ou d’un cache froid. La même logique qui fait que cela vaut la peine d’investiguer un test flaky plutôt que de le relancer s’applique ici.

Ceux que vous ne pouvez pas reproduire, par construction

Certaines défaillances ne peuvent pas être reconstruites sur votre machine, et aucune persévérance n’y changera rien. Les reconnaître tôt vaut mieux que s’acharner.

Il fallait leur horloge. Un appareil dont l’heure est fausse produit des échecs de certificat, des sessions expirées et des horodatages impossibles. C’était trois des cinq causes derrière un avertissement de certificat.

Il fallait leur réseau. Un proxy d’entreprise, un filtre DNS, un portail captif, un opérateur mobile qui réécrit les requêtes. Vous ne pouvez pas rejoindre ce réseau, donc vous ne pouvez pas voir ce qu’il fait.

Il fallait leur build. Un déploiement progressif a placé une fraction des utilisateurs sur une version que personne d’autre n’a, y compris vous.

Il fallait le moment précis. Un déploiement à moitié terminé, un cache froid, un service tiers lent pendant quatre-vingt-dix secondes. L’état qui l’a causé a cessé d’exister avant même que le rapport soit rédigé.

Il fallait leurs extensions. Quelque chose injecté dans la page l’a modifiée. Vous n’avez pas les mêmes, donc vous n’avez pas la même page.

Pour ces cas-là, la question n’est pas « comment reproduire ceci » mais « qu’est-ce qui était vrai à ce moment-là, et puis-je encore le découvrir ? »

Ce qui plaide pour la capture plutôt que la reproduction

Chaque élément de cette liste est invisible après coup et bon marché à enregistrer sur le moment. La console au moment où ça a cassé. La requête en échec avec son statut et son timing. Le build du navigateur, la taille d’écran, l’URL. Rien de tout cela n’exige que le rapporteur sache ce qui compte, ce qui est justement toute la difficulté, car il ne le sait jamais.

C’est l’argument en faveur d’un rapport qui porte ses propres preuves plutôt qu’une description de celles-ci. La reproduction est une façon de récupérer une information qui a été jetée, et elle coûte cher précisément parce que cette information a été jetée.

Redemander au rapporteur, mais correctement

Quand vous devez vraiment y retourner, demandez les choses auxquelles ils peuvent réellement répondre, pas celles que vous auriez aimé qu’ils écrivent.

Mauvais : « merci de fournir les étapes exactes pour reproduire le problème ». Ils croient déjà l’avoir fait.

Mieux, et chacune de ces questions a un taux de réussite correct :

• À quelle heure cela s’est-il produit, et quelle heure indique votre appareil maintenant ? Deux questions, pas une seule. L’écart entre les deux est déjà un diagnostic.
• Est-ce arrivé plus d’une fois ? Une fois, c’est un instant. Plusieurs fois, c’est un état.
• Cela se produit-il sur un autre réseau, par exemple en data mobile plutôt qu’en wifi ?
• Qu’y a-t-il exactement à l’écran ? Les mots exacts, pas un résumé.
• Avec qui d’autre pouvez-vous le reproduire ? Un autre compte ramène le problème aux données ; une autre personne sur le même compte le ramène à l’appareil.

Le guide du rapport de bug présente la structure complète d’un bon rapport, et les erreurs courantes couvrent ce qui manque le plus souvent.

Que faire quand vous abandonnez

Parfois, vous ne pouvez vraiment pas, et fermer le ticket est la bonne décision. Ne le fermez pas juste avec “cannot reproduce” et rien d’autre, car cette phrase n’apprend rien à la personne suivante, qui passera la même après-midi que vous.

Écrivez ce que vous avez essayé. Quel compte, quel navigateur et quel build, quelles données, lequel des quatre axes vous avez fait varier et lequel vous n’avez pas pu tester. Alors le prochain rapport sur le même sujet, venant d’une personne différente avec un détail différent, ne repart pas de zéro. C’est le deuxième point de données, et deux rapports qui partagent un même élément inhabituel constituent en général toute la réponse.

C’est aussi la version honnête du statut. Le bug n’a pas été réfuté. Il n’a pas été reproduit avec les informations disponibles, ce qui est une affirmation différente, et bien plus utile à laisser derrière soi.