Pour cette histoire de Quality Engineering, je reçois Jean-Baptiste Crouigneau, Fondateur et Directeur de Prodigeo, expert du test et de la qualité logiciel basé au Maroc.
Il est consultant, formateur et auditeur sur l’ensemble des activités de test, avec une prédilection pour les aspects de gestion des tests, amélioration des processus et automatisation des tests.
Jean-Baptiste est membre fondateur du CMTL (Comité Marocain des Tests Logiciels), et également actif au sein de l’ISTQB (actuellement membre de l’Exam Working Group) et de la Fondation TMMi.
Nous partageons un projet de définition d’une stratégie de test dans un projet à fort enjeu, suivi par la direction générale, et avec une date fixe de lancement au grand public.
Le projet s’est révélé contenir des objectifs indirects et loin du pur test, d’où le titre “Histoire d’un agenda caché”.
Une forte capacité d’adaptation a été nécessaire pour équilibrer les enjeux de ce projet, complémenté par des éléments éclairants !
Nous partageons ici son retour d’expérience autour des points suivants :
- Suivre des pistes pour sentir le contexte d’intervention
- Cerner les objectifs directs et indirects d’un projet
- Comprendre les attentes réelles des interlocuteurs
- Savoir rester ferme sur ses appuis, convictions et valeurs
- Adapter certains livrables pour qu’ils soient à plus forte valeur
Une bonne écoute, lecture, ou visionnage à votre convenance, n’hesites pas à commenter.
Rejoignez la QE Unit pour accéder à du contenu exclusif régulier via la newsletter.
Antoine: Peux-tu commencer par t’introduire?
Je suis essentiellement expert en test logiciel autour de trois types d’activités.
En premier, je fais de la formation pour partager des expériences notamment le volet ISTQB, assez connu de nos jours, pour ce qui concerne les tests. Mais j’interviens également sur l’ingénierie des exigences.
En second, toujours dans le domaine du test, audit avec le modèle TMMI, moins connu mais similaire au CMMI pour le développement logiciel.
En complément, je fais également du terrain, je participe à des projets, j’accompagne des équipes.
C’est d’ailleurs pour ça que j’ai pas mal d’anecdotes et d’histoires qui se sont accumulées au fur et à mesure du temps.
J’ai donc retenu l’une de ces aventures pour échanger ensemble.
Le contexte du projet
Antoine: Peux-tu nous en dire un peu plus?
Il y a environ quatre ans j’effectuais une mission dans une banque basée au Maroc, où je vis actuellement.
Pour situer le projet, au Maroc comme dans beaucoup de pays, ont été lancées des offres de banque islamique.
C’était assez épars, a mis du temps à venir, et une fois structuré, c’est devenu la course entre les banques.
La banque en question était marocaine et souhaitait créer une nouvelle banque, complètement séparée de l’existante.
Une sollicitation tardive pour un projet stratégique
On nous avait appelé pour décrire la stratégie de test. Comme d’habitude à la dernière minute.
Jean-Baptiste Crouigneau
Antoine: Il n’y avait donc pas de budget ou même de tâches allouées au test ?
Pas exactement, il y avait des choses prévues, mais les développements étaient déjà démarrés et bien avancés, avec une date fixe imposée par la direction.
De base, le planning n’était pas très réaliste. Il nous restait 9 mois avant le lancement officiel du projet.
Antoine: Quel était le périmètre de mise en place, tout le back-office, basé sur un ERP?
Oui c’était bien un périmètre complet, basé sur un ERP spécialisé Libanais, qui fournissait un bon socle.
Malgré tout, il y avait beaucoup de travail dû aux développements spécifiques et à l’effort d’intégration nécessaire.
Nous avons donc commencé à rencontrer les différents interlocuteurs du projet, qui ont rappelé leurs attentes élevées malgré les fortes contraintes.
Au niveau de l’équipe de test, il n’y en avait pas!
Il y avait quatre leaders métiers mais qui n’étaient pas des testeurs et avaient beaucoup d’autres tâches à réaliser.
Le planning et la disponibilité des personnes étaient donc deux contraintes fortes.
Est venu s’ajouter à cela, trois phases de tests qui avaient été prévues et planifiées, sans que nous ayons pu analyser le projet.
Les contraintes fortes forcent à faire un exercice de priorisation
Au vu de ces contraintes, je me suis dit que j’allais estimer la charge, diviser par le nombre de jours qu’ils nous reste, et voir ce qui aurait pu être proposé.
Antoine: Au vu des contraintes de temps et de ressources, cela impliquait-il donc de prioriser un périmètre ?
Oui, effectivement je vais y venir!
Nous avions récupéré des exigences formalisées de haut niveau, entre 500 et 600!
J’ai fais une petite règle de trois sur la phase de test divisée entre conception, implémentation et exécution.
Nous avions identifié entre 500 et 600 exigences, pour plus de 1500 tests « seulement »
Jean-Baptiste Crouigneau
On a également pris l’hypothèse que l’on allait pouvoir obtenir une dizaine de testeurs pour nous aider dans l’implémentation.
En moyenne, avec 3 à 4 tests par exigence, nous étions capables de réaliser en peu plus de 1500 tests.
La première version de la stratégie est froidement reçue
En le présentant à l’équipe projet, ça a été un premier choc pour eux au vu de certaines exigences non-négociables.
On a donc fait un exercice de priorisation par les risques.
Le métier a assigné une valeur et un risque à chaque exigence, pour obtenir une vue des possibilités d’optimisation.
Suite à cette première analyse, quasiment 100% des exigences étaient à un niveau critique, donc sans priorisation possible!
Plusieurs révisions sont nécessaires dans un délai court
Nous avons essayé avec plusieurs aller-retours d’avoir une vraie priorisation, en priorisant les exigences entre elles.
À ce moment, le directeur de projet est revenu vers nous en escalant la date de livraison de la stratégie de test, elle devrait être prête sous trois jours.
De notre côté, on voulait être réaliste et partager la réalité, pas un plan auquel nous ne pourrions pas nous tenir.
Nous n’avions donc pas beaucoup de choix : présenter quelque chose de pauvre pour la date définie, ou demander un délai supplémentaire.
La direction générale étant en attente du projet, nous avions peu d’espérance d’obtenir un délai supplémentaire.
On s’est donc dit qu’on allait tenir les délais, prioriser au mieux, utiliser des techniques de tests plus légères quand cela était possible.
Antoine: Vous avez donc essayé d’optimiser certaines techniques et réaliser un 80/20?
Oui exactement, en complément nous avions prévu d’intégrer des testeurs expérimentés dans le métier de la QA et dans le secteur bancaire.
L’automatisation est poussée par mégarde par le client
Pour en revenir à notre stratégie de tests, l’un des quatre responsables métier a proposé d’automatiser les tests, pour, dans son idée, gagner du temps.
Pour nous ce n’était pas la solution au vu de l’investissement supplémentaire nécessaire à la mise en place de l’automatisation.
J’ai donc poussé pour que l’automatisation ne vienne pas s’ajouter au projet, au contrainte de la proposition intuitive qui avait été faite.
Le jour de la présentation officielle de la stratégie arrive
Les trois jours s’étant entre-temps écoulés, arrive ensuite le jour de la présentation de la stratégie de test.
Nous la présentons donc avec le directeur le projet, les différentes équipes impactées dont l’équipe de développement.
Nous partageons qu’au vu des contraintes prioriser était obligatoire.
Concrètement, nous avions identifié les services qui allaient être nécessaires tout de suite au lancement, par exemple la création de compte.
Les opérations moins fréquentes et pas utiles au démarrage étaient, elles, à réaliser plus tard.
Malgré un focus métier, la présentation n’est pas bien reçue
Notre proposition n’est pas bien reçue et notre présentation tourne mal, à notre grande surprise.
On voit bien que le directeur de projet n’est pas satisfait : c’est trop léger, on ne peut pas prendre ce type de risque sur un projet d’envergure, etc.
En même temps, nous avions tout exposé avec le contexte, les formules de calculs.
Antoine: Vous aviez en plus bien axer la priorisation sur la valeur métier, avec prise en compte de l’expérience client, fonctions et les dates communiquées?
Oui complètement, la proposition était alignée sur le contexte métier.
On est donc un peu mal à l’aise et surpris de ce type de réaction.
Des éléments clefs sont obtenus dans une discussion de couloir
En sortie de la réunion, dans une discussion de couloir, nous obtenons des informations complémentaires.
Nous comprenons de manière indirecte que le directeur de projet, qui nous avait sollicité, voulait en fait démontrer que le projet ne pouvait pas être réalisé dans les temps !
Antoine: Il fallait donc qu’à cause des tests et la QA le projet stratégique soit décalé?
Voilá, il voulait des gens pour soutenir sa proposition de décalage et avait probablement d’autres actions en ce sens.
On a donc bien compris pourquoi notre proposition ne convenait pas, il fallait contribuer à rendre le projet décalable.
Le livrable est adapté pour répondre au réel besoin
Par contre, j’ai développé en complément un petit outil basé sur un Excel pour prioriser les tests.
En rentrant quelques paramètres comme le nombre d’exigences, de tests et de testeurs, il pouvait obtenir des scénarios de charge et de planning.
L’idée était de se dire que l’outil pourrait être utilisé en construction de scénarios et comme un possible argumentaire.
C’était en quelque sorte comme une porte de sortie pour nous, nous permettant d’aller dans son sens.
Antoine: Super intéressant comme rebondissement, on comprend avec le recul quel était l’objectif réel de l’intervention !
Exactement, tout le monde était conscient que le projet n’était pas réaliste.
Sans avoir participé au projet, le lancement a bien eu lieu plus tard que la date prévue.
La compréhension des attentes réelles est un vrai défi
Avec le recul, j’identifie qu’il faut faire attention aux premiers signes avant-coureurs en particulier sur la compréhension des attentes réelles des gens.
Pour livrer ce qui est attendu, il faut être très attentif aux interlocuteurs directs et indirects qui peuvent nous mettre sur des bonnes ou mauvaises pistes.
Faire attention aux premiers signes avant-coureurs et aux réelles attentes des interlocuteurs.
Jean-Baptiste Crouigneau
Garder sa ligne de conduite malgré la pression extérieure
L’autre conseil que je peux donner, en tout cas ma ligne de conduite, c’est de rester ferme sur ses convictions et ses idées.
C’est facile de se faire influencer et adapter un plan pour répondre à une demande plus autoritaire par exemple.
Rester ferme sur ses convictions et ses idées.
Jean-Baptiste Crouigneau
Dans le projet nous avons préféré répondre de façon réaliste en nous confrontant à la réalité, pour permettre aux gens de travailler dans de bonnes conditions, plutôt qu’un plan illusoire.
Ce n’est pas évident quand la pression est forte. Dans notre cas, tous les acteurs clefs et avec influence étaient soumis à une pression forte.
Antoine: On pourrait presque faire un parallèle avec les sports de défense où l’on utilise la force de son adversaire. S’adapter vaut mieux que s’acharner contre courant?
Oui c’est une bonne image, notre objectif était de ne pas finir sur une impasse.
Savoir adapter les livrables et avoir une porte de sortie
On ne poulait pas livrer exactement ce qui était attendu, on a donc proposé une alternative lui permettant d’explorer des possibilités sur des bonnes bases.
Antoine: On aurait presque envie de demander quels sont les objectifs cachés du projet lorsque l’on reçoit une sollicitation !
Exactement, c’est assez compliqué quand on ne connaît pas bien le contexte de l’entreprise.
Il faut essayer de sentir les choses, suivre son instinct, agir comme un enquêteur.
C’est aussi ce qui fait l’expérience.
Antoine: J’ai hâte de pouvoir échanger à nouveau comme j’ai compris que tu avais d’autres histoires et anecdotes à partager!
Oui, pour teaser éventuellement une prochaine histoire.
Elle est composée de deux chefs de projet, la direction générale voulant se séparer de l’un d’eux, et a été sujet à des moments et des apprentissages intéressants…
Suite au prochain épisode!