Intégrer une nouvelle équipe, inculquer l’esprit du test : Mon expérience et mes conseils.
Introduction:
A début je voulais présenter cet article comme une liste de conseils pour bien s’intégrer dans une équipe et inculquer l’esprit du test. Finalement j’ai opté pour une présentation plus personnelle avec des exemples de ma vie professionnelle.
Mon stage de fin d’études chez Kéolis:
C’est à l’occasion de ce stage chez Kéolis que j’ai découvert le métier du test. Je m’occupais en autre de toute la stratégie de test, de l’exécution et de l’écriture des tests mais aussi de la gestion de bugs et de la mise en production.
Je travaillais sur un système de réservation de bus (transport à la demande). Après ma batterie de tests exécutés, tous en succès, je décide de programmer une mise en production… un vendredi après-midi entre 14h00 et 16h00 l’heure creuse pour la prise de réservation. Tout se passe bien et je pars en week-end l’esprit tranquille.
Malheureusement à mon retour de week-end le lundi matin, j’apprends que les réservations par internet ont été suspendues dès le vendredi soir (vers 19-20h00) et que seul les agents de réservation étaient autorisées à prendre des réservations suite à la découverte par un de ces agents d’un bug non couvert par mes tests. Certaines courses proposées duraient 4 heures avec 2 correspondances au lieu d’une seule sans correspondance.
Mes erreurs:
1- Je ne connaissais pas assez les contraintes du métier et n’avais pas assez communiqué avec les agents de réservation qui ont découvert le « bug » très rapidement après l’implémentation.
2- J’ai programmé une mise en production un vendredi alors que le système fonctionnait 7 jours sur 7 et que je ne travaillais pas le week-end.
Mes conseils:
1- Bien connaitre le fonctionnel et l’utilisation du logiciel.
2- Bien communiquer avec les utilisateurs (ou les équipes expertes) de ce logiciel.
3- Ne jamais faire de mise en production avant une absence de quelques jours. Il faut pouvoir avoir au moins 1 ou 2 jours disponibles pour un retour à la version précédente dans le cas où un bug non détecté lors des tests apparait.
Mon expérience chez Orange:
C’est chez Orange que j’ai effectué ma plus longue mission (2 ans). J’étais principalement en charge du test pour les applications mail sur smartphone et tablettes.
Lors de cette expérience j’ai beaucoup appris sur l’écriture des tests, la gestion de projet, la méthode SCRUM, les problématiques d’automatisations les tests vitaux et exploratoires.
J’ai fait ma principale erreur chez Orange lors de mon arrivée. Je sortais d’une expérience qui moyennement passée et je voulais faire de mon mieux. Je débordais donc d’enthousiasme… un peu trop.
Mon erreur:
Lorsque je trouvais des bugs j’allais directement voir le développeur pour lui montrer, je « courrais » partout à vouloir faire le plus de choses possibles. Malheureusement cela a dérangé certaines personnes de l’équipe qui n’appréciait pas cette façon de faire, en effet, des process étaient définis afin de limiter les « interférences ».
Mon conseil:
– Lorsque l’on arrive dans une équipe c’est à nous de nous adapter à l’équipe et aux différentes personnes qui la constitue, pas l’inverse. Alors certes il faut rester soi-même mais certains compromis sont nécessaires, ça tombe bien le métier du test est un métier de compromis !
Mon expérience chez Amadeus :
Encore une mission où j’ai beaucoup appris. Du travail exclusivement en SCRUM tout en faisant partie d’une équipe de test, à l’implémentation de nouveaux process et outils.
Ma principale erreur ici a été une erreur de communication. Je sortais de mon expérience chez Orange où on avait implémenté des tests vitaux. Comme vous le savez si vous avez lu mon article sur les tests vitaux, je suis un farouche défenseur de ces tests. C’est donc avec étonnement qu’en arrivant dans mon équipe je m’aperçus de leur absence.
J’ai donc tout de suite voulu les implémenter afin d’améliorer la qualité du produit.
Mon erreur:
Je venais d’intégrer dans une équipe, sans légitimité, sans avoir prouvé mes compétences ni avoir compris l’ensemble des besoins de l’équipe (finalement les tests vitaux ont été implémentés mais seulement 1 an après mon arrivée) et voulais directement implémenter de nouveaux process et l’esprit de la QA (Quality Assurance).
Mes conseils:
Lorsque l’on rejoint une équipe avant de proposer des améliorations il faut d’abord :
-Bien connaitre son fonctionnel.
– Acquérir de la légitimité au sein de son équipe.
– Connaitre les besoins et les méthodes de travail (qui sont souvent là pour une bonne raison) de notre nouvelle équipe.
Les méthodes de travail de nos anciennes équipes, surement parfaitement adaptée à celles-ci ne le sont pas forcément à la nouvelle.
– Il faut convaincre et éviter d’imposer.
Ma mission chez Air France :
Lors de cette mission j’ai travaillé sur les tests de régression du site internet d’Air France ainsi que sur la migration d’UFT (avec ALM) vers PyXSel (avec XStudio) ainsi que sur les campagnes de tests vitaux.
Mon erreur:
Je voulais que tout soit « parfait » et essayait d’apporter mon expérience et mon avis sur différents projets lorsque j’entendais certaines discussions. Cela a gêné assez rapidement quelques personnes et il m’a fallu plus de temps suite à cela pour acquérir ma légitimité.
Mon conseil:
Lorsque l’on arrive dans une équipe il faut :
– Se concentrer uniquement sur ce que l’on nous demande de faire. Après avoir fait ses preuves les membres de l’équipe viendront naturellement vers nous pour avoir de l’information ou connaitre notre avis.
– Savoir s’adapter à l’existant.
– Ne pas vouloir tout, tout de suite, il faut savoir être pragmatique et apporter des améliorations petit à petit même si elles ne sont pas révolutionnaires ni à la hauteur de ce que l’on souhaite
Conclusion :
Lorsque l’on intègre une équipe, il faut avant toute chose faire ses preuves et être accepté par l’équipe. C’est seulement ensuite lorsque l’on connait bien les contraintes et le fonctionnel que l’on peut apporter un vrai plus à l’équipe.
Enfin, une erreur n’est pas rédhibitoire, j’en ai fait dans toutes mes missions et cela ne m’a pas empêché, à terme, de me faire accepter par les personnes avec qui j’ai travaillé. Comme le disait Mandela « I never lose. I either win or learn »*, le plus important lorsque l’on commet c’est de savoir en tirer les conséquences et comprendre pourquoi cela n’a pas marché (Une erreur n’est pas un échec par contre elle peut y conduire). Tout le monde fait des erreurs et c’est normal (l’erreur est même encouragée dans certaines entreprises afin de faire des retours d’expériences), par contre tout le monde n’en tire pas nécessairement les bonnes conséquences.
« I never lose. I either win or learn »: Je ne perds jamais. Soit je gagne soit j’apprends.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
Transport à la demande : http://mobiter.iternet.org/tad.htm
La taverne du testeur 
Publié par