Licence CC 0

Speedrunnez vos bugs

(glitch autorisés)

Imaginons nous un jeu. Comme pour un speedrun, le but ici est de le finir le plus rapidement possible, mais de manière reproductible (100% de réussite). Par contre, il ne s’agit pas d’un Zelda, Mirror’s edge, Mega man, mais ici, il s’agit de trouver la raison de pourquoi votre logiciel de messagerie reçoit bien les notifications de messages entrant, mais n’affichent pas les messages au client (du beau nom de : bug 1564).

En voici un court synopsis:

Eli, une personne utilisant le logiciel pour communiquer avec Clem, voit des notifications de messages entrant ou d’appels de Clem, mais la fenêtre où s’affiche la conversation avec Clem reste vide. L’énigme ici est de trouver pourquoi l’affichage ne se fait pas à ce moment, même si ce comportement est résolu si Eli supprime et remet Clem dans ses contacts.

Finir le jeu une fois

La première étape ici est d’arriver à finir le jeu, au moins une fois. Vous savez que le jeu est possible car vous l’avez vu une fois. Mais ce n’était pas vous le joueur, donc ce n’est pas marrant.

Vous tentez alors plusieurs approches, à plusieurs endroits de la map. Mais vous voyez toujours les messages de Clem, sans succès. Un moment vous trouvez une zone bizarre sur la carte, un glitch dans un coin et tentez de passer en forçant (littéralement en vous énervant un peu sur la manette, où ici en combinant supprimer/ajouter le contact, fermer/ouvrir l’application, envoyer des messages à Clem). Et, d’un coup, miracle, vous vous trouvez en dehors de la map, derrière le mur, vous arrivez à voir Clem dans vos contacts mais plus ses messages.

Vous avez réussi le jeu, mais au pif.

S'entraîner

Vous connaissez maintenant la zone qui contient le glitch. Mais vous comprenez pas encore trop comment réussir à aller dedans à 100%.

Le but, maintenant est d’essayer de trouver comment reproduire ce glitch pour aller directement à l’endroit voulu. Et pour ceci, il y a la super arme du développeur : le papier/crayon + trace. Il suffit ensuite de reproduire plusieurs séries où vous tentez de glitcher. Vous allez alors arriver à glitcher de plus en plus souvent et reproduire le comportement voulu de plus en plus vite.

Ainsi, d’un bug un peu mystérieux, vous allez pouvoir obtenir un bug reproductible et donc plus facilement travailler dessus.

Par exemple, pour ce jeu, obtenir la série suivante pour glitcher et passer à la fin :

  • Clem appelle Eli.
  • Eli accepte l’appelle, raccroche.
  • Eli stop/relance l’application.
  • Eli supprime Clem des contacts.
  • Eli stop/relance l’application.
  • Eli ajoute Clem des contacts.
  • Clem appelle Eli.
  • Eli accepte l’appel, raccroche, resupprime Clem.
  • Eli stop/relance l’application.
  • Clem appelle Eli, Eli glitch et ne voit plus les messages de Clem.

Bien sûr, le speedrun n’est pas forcément parfait, et sera peut-être amélioré par un autre joueur, mais vous êtes passé d’un jeu quasi impossible, à un jeu que vous terminez à chaque fois.


Au final, ce billet n’a pas vraiment de but précis, il s’agissait juste d’une réflexion que j’ai eu un soir en rentrant sur le fait de tester un programme avait des points communs avec le fait de speedrunner un jeu.

Mais pour le fin mot de l’histoire, ce billet est inspiré d’un bug de duplication de contact que j’avais sur un logiciel parce qu’il stockait les contacts d’une mauvais façon, qui pouvait amener à une duplication des contacts.

6 commentaires

J’ai travaillé pas mal en support de production dans l’électronique et ce que tu décris içi n’est que la première partie de ce qu’on appelle la recherche de la cause racine (ou root cause) et que tu nommes "origine du bug".

Si la panne d’une carte (ou d’un calculateur) n’est pas très précise, il faut trouver des moyens de réduire la zone de recherche rapidement et réaliser des manipulations permettant de vérifier le bon fonctionnement de fonctions de manière la plus isolée en fait partie.

Sur des calculateurs comportant plusieurs cartes, on réalise aussi des substitutions pour savoir quelle carte est en panne si le message d’erreur est trop général. On dispose de cartes garanties bonnes et l’on vient remplacer chaque carte une par une et on vérifie le résultat du test.

La seconde étape, en général une fois que l’on a une idée plus précise de qui pourrait être le fautif, c’est de réaliser un arbre des causes et de "tuer" le maximum d’hypothèses. :)

Il est vrai que pour l’électronique, l’avantage de pouvoir remplacer pièce par pièce aide pas mal par contre :)

AmarOk

T’as (dans le cas d’une régression) une méthode analogue sur du code en supprimant ou ajoutant des commits de la même façon que tu remplaces des cartes électroniques. L’avantage par rapport à l’électronique étant que les commits sont en plus organisés en graphe orienté, ce qui permet d’utiliser une bissection pour faire ta recherche du commit fautif.

+3 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte