Vis ma vie de QA : investigation d’un bug potentiel en prod

Arrivée au bureau. Après vérification de mes mails et messages slacks, je vérifie le résultat des tests automatiques exécutés pendant la nuit.

Traiter et analyser les tests qui ont échoué

Sur plus d’une centaine de tests exécutés, quatre ont échoué. Jusque-là, rien d’alarmant.

J’affiche les tests ayant échoué et prends le temps de vérifier leur nom pour trouver d’éventuels points communs entre ces tests.

Pour chaque test ayant échoué, je regarde ensuite la vidéo dudit test afin de déterminer la raison de l’échec.

L’un des tests souscription mobile a échoué car un clic sur un bouton s’est mal passé (le clic ne s’est pas fait). Il s’agit d’un bug dans mes tests et non pas dans l’app testée. C’est un problème connu que je n’ai pas encore eu le temps de régler. Je passe à la suite.

Deux tests ont échoué à cause du mandat de prélèvement qui mettait trop de temps à se générer. Ce problème est un problème connu qui survient de temps en temps. Un message d’erreur adéquat a été affiché. Tout va donc « bien » et il n’est pas nécessaire de s’inquiéter (sauf si le problème persiste au cours du temps, auquel cas il faudra creuser un peu plus).

Enfin, un dernier test semble avoir échoué sans raison apparente. Aucun message d’erreur n’est présent sur la vidéo du test et la page affichée semble « aller bien ». Je regarde si une erreur ne se cacherait pas dans les logs network, cependant, là encore, tout va bien. Il va falloir creuser un peu plus. Heureusement, je sais déjà que s’il y a un problème, c’est un problème qui affecte peu d’utilisateurs puisque tous mes autres tests vont bien.

Identifier la cause de l’échet de ces tests

Pour commencer, je relancer les tests depuis GitLab pour voir si le problème se reproduit.

15 minutes plus tard, les tests ont fini de se rejouer et le problème est toujours là. J’ouvre donc mon IDE (càd : mon environnement de développement) afin de lancer le test fautif en local. Cela me permettra de lire les logs plus facilement et d’effectuer des actions manuelles sur l’application testée pendant et après l’exécution du test.

 Après lecture des logs, il semblerait qu’un clic sur un bouton n’ait pas fait apparaitre le texte attendu.

Résoudre le bug « à la main »

À la main, je vais moi-même cliquer sur ledit bouton. Rien ne se passe. Le bouton ne semble pas avoir enregistré le clic.

J’affiche les logs réseaux (à l’aide de mon ami le bouton F12), recharge la page et re-clic sur ledit bouton. Toujours rien. Et les logs réseau ne montrent rien non plus.

Le problème ne semble pas venir des tests automatiques mais bien de l’application en elle-même. Il est temps de prévenir l’équipe en charge de l’app.

Prévenir l’équipe dont dépend le bug

J’envoie un message via l’application « Slack » sur le channel qui va bien en taguant toute l’équipe. Je donne tous les détails nécessaires afin de permettre à n’importe qui de reproduire l’erreur. Et comme le problème est en production et semble non-mineur, je me charge d’appeler la personne référente sur le projet afin de m’assurer qu’elle soit rapidement informée des problèmes sur l’application.

Correction du bug tous-tes ensemble

Pour corriger le problème au plus vite, une « war room » se met en place. Elle réunit toutes les personnes susceptibles d’aider à la résolution du problème. Et notamment les développeurs-ses de l’équipe concernée par le bug.

De mon côté, je teste diverses choses à la main afin de déterminer au mieux les conditions d’apparition du bug. Cela pourrait apporter des indices précieux pour la résolution du problème.

Une solution de contournement du problème est trouvée, testée, mise en prod et re-testée.

Le traitement de l’incident après résolution

Quelque temps plus tard, une solution définitive sera mise en place. De mon côté, je confirmerai via mes tests auto et des tests manuels que le problème a effectivement disparu.

Un « post mortem » pour revenir sur l’origine de l’incident (et mettre en place des solutions pour éviter qu’il ne se reproduise) est prévu pour dans 3 jours. J’y participerai en tant que QA. Durant cette réunion, la mise en place d’un test de monitoring sera décidée.

Chez Ekwateur, nos applications font appel à de nombreuses dépendances et partenaires internes et également externes. Ainsi, le moindre changement ou problème chez l’un de ces partenaires peut avoir un impact chez nous.

Ce qui peut sembler être une mise à jour mineure chez un partenaire peut entraîner des répercussions inattendues et catastrophiques chez nous.

Ainsi, faire des tests après une Mise En Prod (aussi appelé « MEP ») n’est pas suffisant. Il faut également monitorer les applications (internes ET externes) en permanence au cas où un problème inattendu survienne.