Introduction
J’ai découvert le test lors de mon stage de fin d’études. A cette époque je ne connaissais pas du tout le métier qui ne m’avait jamais été présenté (l’intitulé du stage n’avait d’ailleurs pas le mot « test ») et n’avait pas conscience qu’il était possible d’en faire son métier.
Mon stage de fin d’étude s’est déroulé dans une entreprise de transport public. Le nombre d’employé était conséquent (presque 1000) mais mon département Recherche et Innovation était composé de 4 personnes (2 stagiaires, un responsable et un CDI), ce qui est parfaitement cohérent car l’essentiel des effectifs étaient des conducteurs et des mécaniciens pour gérer la flotte.
L’objet de mon stage était de finaliser la mise en place d’une solution permettant aux usagers des lignes de transport à la demande (des lignes de bus dont les courses ne sont déclenchées que s’il y a des réservations et ne desservent que les arrêts qui en ont) de réserver jusqu’à 30 minutes avant l’heure théorique de passage du bus au lieu de 2 heures. Cette avancée pour les utilisateurs n’était pas conséquence car forçaient à dématérialiser les réservations et fournir ces informations en temps réels aux conducteurs (les courses aller-retour durant 1h30). Pour réussir cela la société avait décidé d’implémenter un nouveau logiciel de réservation qui serait relié à des systèmes embarqués dans les bus grâce au réseau 3G.
Le contexte ne permettant pas à la société de développer ses propres logiciels et systèmes embarqués elle avait passé des commandes à des sociétés tierces pour de développement du système embarqués, du logiciel de réservation et du logiciel embarqué. Mon rôle était de concevoir les campagnes de test, d’exécuter les tests puis de faire des campagnes de mise en situation.
Collaborer avec les utilisateurs
Je suis arrivé en février au moment de la livraison du logiciel de réservation. La personne que je remplaçais m’a présentée le projet et indiqué le travail que je devais faire. J’ai alors, « dans mon coin », conçu des tests et une campagne que j’avais rempli dans un fichier Excel. Pour les anomalies nous avions Mantis qui permettait de communiquer les bugs à la société développant le logiciel.
Lorsque ma campagne fût terminée et le niveau de qualité jugé « suffisant » j’ai présenté, fait une démonstration et formé les agents de réservation à l’utilisation du logiciel. Une mise en production a alors été faîte un vendredi après-midi. Je partais en week-end l’esprit libre avec le sentiment de travail accomplit.
En arrivant le lundi matin, je m’aperçois que j’avais reçu un très grand nombre de mails pendant le week-end (les bus roulent aussi le week-end !). Une erreur majeure (qui aurait été critique si les agents de réservations n’avait pas été vigilants) se trouvait dans le logiciel. L’algorithme de réservation ne prenait pas les réservations qui permettaient d’arriver le plus tôt à la destination mais le bus qui partait le plus tôt quitte à faire des correspondances et des boucles. On pouvait se retrouver pour un trajet « A => B » à faire « A => C => A => B » et arriver 2 heures plus tard.
Nous avons alors fais un roll-back puis corrigé l’anomalie. Conscient de mes lacunes, j’ai décidé de collaborer avec les agents de réservations pour concevoir les tests mais nous avons également organisé des sessions de tests exploratoires afin de s’assurer de la qualité.
Grâce à cette collaboration, nous n’avons plus connu de bug majeur sur les versions suivantes.
Créativité dans les investigations
Les systèmes embarqués, qui étaient attendus en mai juin nous ont finalement été livrés en juillet. Entre temps j’avais préparé ma campagne en concevant mes tests et en collaborant avec les responsables des dépôts afin de m’assurer de la pertinence de ceux-ci et de l’ensemble de la campagne.
A la livraison nous avons fait des essais directement dans un bus pour valider que les branchements étaient fonctionnels et que le réseau téléphonique était suffisant. Suite à cela j’ai commencé des tests avec peu de données et dans mon bureau.
J’ai alors organisé des sessions de formation pour les conducteurs. Dans un souci de pertinence j’avais implémenté les données de telle sorte que cela soit proche de la réalité (nombreuses courses, nombreux clients…) … l’histoire m’a donné raison, lors des formations, les systèmes embarqués « freezaient » au bout de 30 minutes d’utilisation et se retrouvaient hors service pendant au moins 30 minutes. Les systèmes embarqués étaient inutilisables en condition réelles !
J’ai alors dû investiguer. Savoir d’où venait le problème et pour cela il m’a fallu faire preuve d’imagination et de créativité.
- Première hypothèse, le problème était lié au système utilisé en test. J’ai alors testé tous les systèmes 1 par 1 : tous avaient les mêmes symptômes.
- Deuxième hypothèse : le problème venait potentiellement des bus et de la tension (qui se trouvait être très variable après mesure). J’ai tenté la même expérience sur mon bureau avec les données faites sur les bus : même problème.
- Troisième hypothèse : le problème venait du volume des données. J’ai fait des tests avec différents volumes. Plus le volume était important plus le problème survenait tôt : il fallait maintenant savoir pourquoi !
Suite à cette découverte j’ai voulu savoir ce qui posait problème. Le problème était lié au système en lui-même ou à ce par quoi passait les données, c’est-à-dire la partie « téléphone ». J’ai alors créé un protocole de test nécessitant de démonter les systèmes embarqués. Ce protocole ressembler à cela :
- Prendre 2 systèmes embarqués
- Les « ouvrir » pour avoir accès à la partie téléphone
- Faire planter un système embarqué
- Echanger les modules téléphoniques des 2 systèmes embarqués
- Vérifier le fonctionnement des 2 systèmes.
Importance de la communication
Le résultat de cette expérience fut que le problème venait du module téléphonique. En effet le système embarqué qui se retrouvait avec le module qui avait freezait ne fonctionnait pas alors que celui qui avait freezé mais dont on avait changé de module fonctionnait correctement.
J’ai alors pu communiquer à la société qui nous avait livré le système embarqué le problème afin qu’elle puisse le résoudre.
Je leur ai envoyé le résultat de mes investigations par mail leur ai téléphoné et leur ai servi de support ce qui a permis de faciliter leurs investigations et trouver rapidement le problème. Au final c’était une limitation de la version du Linux embarqué qui ne pouvait pas supporter plus qu’un certain volume de données. Le problème a été résolu avec une mise à jour de ce système d’exploitation.
Conclusion
C’est cette première expérience dans le test qui m’a fait choisir ma voie. J’ai été particulièrement attiré par le défi intellectuel et les différentes interactions qui m’ont été nécessaires pour réussir cette mission. Au final, ce que je retiens de ce stage c’est ce qui m’a permis de m’améliorer et améliorer les produits : la collaboration, la communication et la créativité (avec la conception de tests et de protocoles). Cela n’aurai d’ailleurs jamais été possible sans un minimum d’esprit critique et de remise en question.
Article écrit pour la belle initiative 21stskills4testers.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
