La parenthèse dans notre dernier événement “Comment réussir son projet d’automatisation de tests? (en transverse) n’était pas anodine,
Je remercie les participants suivants pour leur présence et contribution :
- Iman Benlekehal, spécialiste en Assurance Qualité Logicielle
- Benjamin Butel, passionné du test, software engineering in Test chez Klaxoon, organisateur du Ministry of Testing Rennes
- Xavier Pigeon. Expert méthode et stratégie Qualité & IT, auteur de gearsoftesting.org et fondateur TestAsYouThink
- Anass El Bekali, CEO QSI Conseil, Président du CMTL
- Clément Vannouque, QA Lead chez Decathlon,
- Benoit Civel, Responsable du pôle de solutions digitales chez Auchan
- Soraya Azzaoui, Test Leader chez Pictime Groupe
- Siham Amzile, Consultante Qualité Logicielle chez Henix
Dans cet événement, nous avons abordé les points suivants :
- Quelles grandes étapes dans une démarche d’automatisation?
- Quelles actions doit-on faire pour sécuriser au plus tôt l’initiative?
- Quelles questions se poser, quelles pratiques, à quelles étapes?
Contextualisation de l’événement
Les projets d’automatisation de tests ont un taux d’échecs forts, présentant de réelles difficultés et particularités à appréhender.
Il est malheureusement souvent délégué à la QA, à un stagiaire, ou se résume à un aspect d’outillage.
En guise d’échauffement nous avons rempli le cercle suivant présentant des étapes traditionnelles d’un projet d’automatisation.
L’objectif était de poser nos idées dans les différentes catégories, le plus au centre en fonction de son importance.
À partir de cette base, Clément a démarré un partage d’expérience actuel qui a initié le fil conducteur de notre conversation.
Au travers des échanges, plusieurs points clés sont ressortis et sont explicités dans les sections suivantes.
Évaluer la pertinence des réels enjeux du projet, au plus haut niveau
Une difficulté majeure rencontrée se retrouvait autour d’un manque global de support de la qualité.
Ce point nous a fait rapidement converger vers le niveau de visibilité, compréhension et de support de l’organisation pour la démarche d’automatisation.
Les équipes Produit se retrouvent en premières parties prenantes de ce travail de conviction, mais le top management n’est souvent pas adressé.
On pourrait penser que les projets d’automatisation ne valent pas la peine de solliciter des personnes du management, “qu’elles ont mieux à faire”.
C’est effectivement une réponse possible si le sujet est techniquement partagé, l’automatisation doit rester un moyen d’objectifs clairement exprimés.
Deux questions importantes en transverse : “Pourquoi” et “Pour quoi”.
Iman Benlekehal
Par ces deux questions, “Pourquoi” et “Pour quoi (faire)”, on prend de la hauteur et doit pouvoir articuler en quoi l’automatisation va aider à remplir un ou des objectifs métiers.
C’est ici qu’un sponsor métier est à aller chercher et convaincre.
Nous avons identifié des exemples récurrents d’objectifs dont il est possible de s’inspirer :
- Accélérer la livraison de fonctionnalités pour le client tout en maîtrisant l’expérience utilisateur.
- Améliorer la stabilité des fonctionnalités coeurs du produit malgré les nouvelles versions
- Améliorer la performance des équipes et leur moral par la libération de temps précieux passé sur des tâches répétitives
Ces points restent des exemples qu’il faut obtenir par les parties prenantes dans son contexte, l’écoute active sera clef.
L’exercice suivant sera de clarifier comment les livrables du projet d’automatisation sont alignés avec les objectifs métiers définis.
Mais que faire faire si nous n’arrivons pas à convaincre, malgré un argumentaire préparé?
Confronter les différents acteurs à la “froide” vérité
Nous avons échangé autour de cette problématique souvent rencontrée dans des équipes où seule la date de la livraison compte, au plus tôt, au détriment d’autres objectifs comme la qualité.
Divers éléments sont ici à prendre en compte : nous sommes des êtres d’habitude, une culture met du temps à évoluer, les personnes orientées résultats ne changeront pas.
Un électrochoc est donc souvent nécessaire dans ce type de contexte : l’équipe se rend-t-elle compte de la non-qualité et dans quelle cercle vicieux elle est embarquée?
Est-ce que l’équipe a été confrontée à la qualité des livrables? C’est un électrochoc nécessaire.
Benjamin Butel
C’est en fait rarement le cas avec le niveau de recul nécessaire.
De notre partage nous avons identifié que cette douche froide est nécessaire.
Nous avons identifié que les arguments les plus utiles sont du points des différentes membres de l’équipe et du client final du produit.
Par exemple, l’équipe a-t-elle conscience du niveau de dette technique accumulée et du retard additionnel à chaque développement? Quels indicateurs sont à disposition pour montrer l’état et son évolution?
Mesures-t-on l’impact pour le client de la non qualité? Nous citerons le nombre de dysfonctionnements rencontrés, lenteurs, retards de livraison, dégradations lors de livraison.
L’aspect humain est aussi à prendre en compte, les membres de l’équipe sont probablement stressés, avec un nombre d’heures accumulées, de la frustration de tâches de rework.
Cette douche froide est pour nous nécessaire pour impulser une nouvelle dynamique, dont il convient d’en définir les contours.
Proposer une démarche plutôt qu’un projet
Notre avons identifié qu’un projet d’automatisation a plus de mérite à s’aborder comme une démarche.
Quelles différences?
Un projet est une organisation souvent temporaire qui vise à remplir des objectifs définis dans un cadre donné de délais, coûts, qualité.
La réalité d’un produit logiciel en développement est assez différente :
- Le produit évolue, l’automatisation de tests requiert donc une maintenance adéquate, l’IA n’étant pas encore là pour nous automatiser ce travail.
- Le produit est co-construit, la qualité et l’automatisation a donc plutôt vocation à l’être également que réalisée en silo à posteriori.
- Les processus d’automatisation de tests doivent être intégrés à ceux de création du produit, d’où un besoin d’adaptation dans le temps.
Une démarche quant elle peut se définir autour de deux de ces définitions :
- “Une façon de marcher”.
- “Un raisonnement, une manière de penser.”
Si l’on dédie un sprint à du refactoring, on est plus vraiment dans l’agile. On perd l’apport itératif et incrémental de la qualité dans le cycle de livraison.
Xavier Pigeon
Concrètement pour un projet d’automatisation, on va plutôt vouloir mettre en place des pratiques, une manière de penser et de collaborer qui s’instruit dans le temps.
Il faut néanmoins avoir des étapes définies avec des objectifs précis, pour que notre démarche nous mène vers des résultats escomptés.
On peut d’ailleurs plus facilement faire le parallèle avec les démarches d’agilité qui supportent la mise en place via une démarche incrémentale et piloté par la valeur.
Nous en arrivons au point suivant : faire que la démarche de qualité et d’automatisation soit un sujet de l’équipe.
Inclure toute l’équipe dans la démarche et l’ownership de la qualité
Est-ce que le product owner et les développeurs considèrent la qualité comme critère dans leur tâches quotidiennes?
Si c’est le cas, le chemin d’une inclusion de la qualité en amont, tout au long du cycle de construction et de sa livraison est en bon chemin.
La qualité est l’affaire de tous, pas uniquement de la QA.
Iman Benlekehal
Nous avons par exemple échangé sur la Definition Of Done, qui peut être un reflet concret de cette prise en compte par l’ajout de critères de qualité.
La pratique de session de test et de qualification en commun a également été partagée comme utile à l’amélioration du produit, de la collaboration et de la compréhension mutuelle.
Le pilier d’un sponsor transverse a été également été remonté comme différenciant dans la mise en place d’une démarche de qualité, de par son poids et transversalité dans l’organisation.
Obtenir le bon sponsor et niveau d’expertise au bon moment
Un sponsor peut vraiment faire la différence pour le projet.
Il reste néanmoins à réussir à le convaincre des apports du projet. Parler apport métier et valeur pour l’organisation est nécessaire.
Un sponsor convaincu est ce qui peut également donner accès à des ressources supplémentaires pour sécuriser son projet
Le sponsor est un élément structurant d’un projet d’automatisation.
Anass El Bekali
Il faut parfois savoir se faire aider et accepter une perspective différente.
L’apport de l’expertise peut avoir son sens dans une initiation de projet d’automatisation afin d’en sécuriser l’organisation.
Les décisions coûteuses sont souvent prises en amont, pas dans un choix spécifique opérationnel effectué par la suite.
Cet apport peut être de différentes formes, un audit initial, une expertise ponctuelle dégressive le long du projet, une consultation sur un point spécifique.
Le principal est d’avoir l’humilité nécessaire et de l’utiliser à bon escient dans le contexte en question, et d’en savoir défendre l’investissement budgétaire.
Un projet d’automatisation de tests requiert une approche transversale
On décerne un besoin de verticalité avec le top management jusqu’aux équipes et d’une transversalité afin de réussir son projet d’automatisation.
Une démarche reste plus importante au-delà d’un projet qu’on peut idéaliser avec un début et fin un peu trop fermés.
Une approche itérative et incrémentale reste clef pour valider l’apport de valeur graduelle et adapter les processus, outils et organisations à la réalité.
Certains éléments ne sont pas faciles à obtenir mais feront la différence, tel qu’un sponsor ou une expertise.
Une douche froide pour se confronter à la réalité nous semble également souvent l’étape par laquelle passer pour impulser l’électrochoc suffisant.
D’autres événements sont à venir, j’espère que notre partage vous aura été utile, retrouvez le contenu disponible sous divers formats audio, vidéo.
Rejoignez la QE Unit pour accéder aux contenus en avance, restez au courant des actualités, recevez du contenu exclusif à ce canal.
Contenus évoqués
Scrum Life & Jean-Pierre Lambert