Contexte
Cadre de l’expérience
J’ai de la chance, même si je n’ai pas étudié le test en école d’ingénieur j’ai vite été amené à me plonger dedans. En effet, mon stage de fin d’étude en 2011 était un stage d’AMOA (Assistance à Maitrise d’Ouvrage) mais sur un projet important qui touchait à sa fin. J’ai donc été amené à faire les parties liées au test, à la mise en production et à la formation des utilisateurs.
Le client
Je travaillais pour un acteur des transports public. Il n’y avait pas d’équipe informatique pour le développement des logiciels. Ces derniers étaient externalisés et je jouais le rôle du client. L’externalisation se faisait aussi pour la construction des systèmes embarqués à intégrer dans les bus utilisés pour le transport à la demande.
Un transport à la demande par bus c’est des lignes avec des horaires de bus qui ne sont déclenchées que s’il y a des réservations sur la course en question. Le bus ne dessert alors que les arrêts avec les réservations. L’intérêt de ce type de ligne est de proposer un service de transport public avec des horaires réguliers la nuit et les jours fériés tout en s’assurant que les bus ne vont pas rouler pour rien.
Les logiciels à tester
Le service à apporter avec les logiciels à implémenter était de permettre aux utilisateurs de réserver avec 30 minutes d’avance au lieu de 1h30.
Cela demandait une refonte importante du processus de réservation mais aussi une numérisation. En effet, avant la mise en place de ce service les courses étaient imprimées sur du papier. Une course étant d’environ 30 minutes en 2 fois (un aller et un retour) avec un bus qui partait du dépôt il fallait connaitre les réservations au moins 1h30 avant.
Pour passer à 30 minutes il a fallu:
- modifier le logiciel de réservation pour qu’il soit capable d’envoyer des information à un système embarqué
- avoir des systèmes embarqués qui reçoivent les informations en temps réels et ce même avec un mauvais réseau téléphonique (pas de 4G généralisée en 2011!)
De même, nous en avions profité pour permettre aux utilisateurs de réserver en ligne plutôt que par téléphone.
Le système global à tester était donc composé de 3 logiciels.
Les activités
Activités planifiées
Les logiciels étant variés mes activités l’ont également été.
Les principales étaient:
- Définir un répertoire de test pour chaque logiciel (embarqué, réservation agent et réservation en ligne)
- Exécuter les tests sur l’ensemble des logiciels
- Gérer les bugs et assurer le lien avec le prestataire de développement sur Mantis
- Investiguer les bugs pour trouver les causes racines
- Faire des rapports de campagnes de test
- Préparer et planifier les mises en production
- Assister aux mises en production et assurer des tests vitaux suite à la livraison
- Préparer les supports de formation
- Former les utilisateurs
Activités non planifiées
La planification c’est très bien… Malheureusement il y a souvent des imprévus qui nécessitent des actions et activités complémentaires.
Parmi ces imprévus il y a eu principalement:
- un problème sur le système embarqué qui ne fonctionnait plus après 30 minutes de formation dans un contexte de simulation d’usage en production
- un algorithme de sélection des courses qui pouvait proposer un trajet de 3 heures au lieu de 1 heure (A->C->A->B au lieu de A->B car le bus avec le trajet A->C partait avant celui avec le trajet A->B)
Cela a engendré ces activités:
- Travail en profondeur sur le système embarqué pour trouver d’où venait le problème en conditions réelles. Après plusieurs jours d’investigation j’ai trouvé que le problème venait du volume de données transféré. A partir d’un certain volume (qui augmentait avec l’accueil des clients) le système embarqué se bloquait. Il s’est avéré que le problème venait de la version Linux.
- Une suspension des réservations en ligne et un passage obligatoire par les agents de réservation pour éviter d’avoir des trajets trop long le temps de corriger le problème.
- La mise en place de sessions de tests exploratoires des versions du logiciel de réservation avec les agents de réservation pour s’assurer de la cohérence des données
- Les mise en production en urgence de logiciels
- La prolongation de mon stage pour assurer une version minimale stable en production
- Une documentation des tests et des risques
Ce que je retiens de cette expérience
Je me considère très chanceux d’avoir eu une belle première expérience comme celle-ci.
J’étais dans un environnement bienveillant: personne ne m’a blâmé pour la MEP qui a engendré le bug majeur, j’ai été entouré et conseillé et on m’a laissé une grande liberté d’action.
De même, être dans ce contexte m’a permis de travailler sur:
- les processus et les approches de test
- la communication
- la documentation
- les investigations
- les formations
De même, mes échecs m’ont permis d’identifier des axes d’amélioration importants:
- pas de MEP le vendredi (car oui le bug était resté tout le week-end avec les agents de réservation qui ont dû gérer comme elles le pouvaient les mauvaises réservations)
- l’importance de bien tracer les tests
- inclure le métier lors des tests pour bien comprendre son besoin
- proposer des sessions de tests exploratoires
En bref c’était une belle expérience avec de beaux enseignements… Elle a été un facteur essentiel dans mon choix de carrière: le test!
Conclusion
Tout le monde commence junior. Mes erreurs de stagiaires ne sont pas acceptables pour un senior. Néanmoins ces erreurs sont formatrices et nécessaires. Elles forgent l’expérience et nous permettent de nous améliorer. L’important n’est pas tant de faire ou non des erreurs plus ou moins importantes mais bien de savoir utiliser ces erreurs pour grandir.
Et vous, quelle a été votre premier contact avec le test ?
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.
