Nous avons partagé avec la communauté portugaise sur le thème : “Comment réussir son projet d’automatisation de tests? (en transverse)”
Je remercie les participants pour leur participation et contributions :
- Filipe Carvalho, Engineering Manager chez TalkDesk,
- Joel Oliveira, Senior Project Manager & Test Evangelist,
- Ricardo Lopes, QA Lead chez Feedzai,
- Marco Pedro, “Making Legacy Software Great Again”,
- Diogo Carvalho, Software QA Tester chez Smart Consulting,
- João Santos, Freelance QA Tester,
- Fábio Barbosa, Test Automation Engineering at Basecone
Dans cet événement, nous avons partagé les points suivant autour des projets d’automatisation de tests:
- Quelle est la valeur attendue du projet pour le business?
- Aligner sa stratégie de test sur les besoins métiers, pas sur une pyramide générique
- La quantité n’est pas la qualité, piloter par la valeur et la réduction du risque
- La valeur est dans l’utilisation des tests, la rapidité d’exécution est souvent clef
- Les tests ont besoin de conception comme tout autre activité d’ingénierie
- Avoir une démarche incrémentale sur des fondations stables
- L’importance de la formation des équipes à la qualité
- La qualité est une responsabilité transversale que l’équipe doit composer
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 sont malheureusement souvent délégués à la QA, à un stagiaire, ou se résument à un aspect d’outillage.
En guise d’échauffement nous avons rempli le cercle suivant présentant des étapes traditionnelles d’un projet d’automatisation.
Nous avons dans un premier temps poser nos idées dans le cercle, le plus au centre en fonction de leur importance.
À partir de cette base, la conversation a démarré par le partage de Marco sur un cas d’automatisation de tests dans son contexte professionnel.
Les prochaines sections partageant les points clefs que nous avons identifiés prenant de la hauteur.
Quelle est la valeur attendue du projet pour le business?
On est assez vite revenu aux fondamentaux, parfois trop vite survolés : qu’attends t-on réellement du projet d’automatisation?
Cela peut paraître évident mais les organisations en silos ont tendance à rendre obscur le réel besoin.
Parfois le même peut aussi être lancé dans un silo spécifique sans lien global.
De mon point de vue cette initiative doit vite être raccroché à un enjeu de l’équipe transverse et plus globalement dans l’entreprise.
Comme pour l’événement réalisé avec la communauté francophone, les questions “Pourquoi” et “Pour quoi” restent fondamentales et doivent avoir une réponse claire, de préférence à niveau stratégique de l’organisation.
Cela rejoint le point du besoin de sponsor du projet, accompagné d’une prise de conscience de la non-qualité face aux enjeux du métier.
En résumé, trouver un moyen d’identifier et de partager la valeur métier avec les parties prenantes fera la différence pour le projet.
Aligner sa stratégie de test sur les besoins métiers, pas sur une pyramide générique
Nous avons abordé un second point en relation avec le besoin métier : quels tests mettre en place?
Une première réponse instinctive pourrait être de se référer à un modèle de pyramide de tests, utiles pour fournir un cadre.
L’inconvénient des modèles est qu’ils sont extraits de pratiques plus générales hors d’un contexte. Dans le cas du test, le besoin métier est en partie abstrait de l’équation.
Les pyramides de tests ne sont pas directement alignées avec le besoin métier.
Joel Oliveira
On peut donc facilement se retrouver à faire beaucoup de tests unitaires, sur une application qui avait en fait plutôt un enjeu d’automatiser des tests critiques fonctionnels bout en bout.
Notre lecture a été de :
- Commencer par aligner les besoins métiers
- Identifier les techniques de tests les plus pertinentes.
Ensuite seulement se pose la question de l’automatisation en fonction des ressources, des outils disponibles, de la maturité de l’équipe.
La quantité n’est pas la qualité, piloter par la valeur et la réduction du risque
Montrer des résultats en automatisation est souvent associé à atteindre un pourcentage élevé de couverture ou de valeur absolue de tests automatisés.
Mis à part le possible effet flatteur et un besoin d’ego personnel rempli, ce type de métrique se révèle souvent être le mauvais objectif.
Une couverture ou nombre de tests peut être un métrique en support de la mise en place d’un processus, mais en aucun cas l’objectif à atteindre, encore moins un indicateur de performance métier.
Nous avons plutôt partagé de piloter par la valeur des tests au sein du processus. Par exemple permettent d’ils de :
- Déployer en production avec confiance pour les clients?
- Faire gagner un temps précieux à des personnes de l’équipe?
- Réduire des risques liés à des scénarios particuliers?
La quantité n’intervient pas comme un critère premier, il convient donc de se focaliser sur des indicateurs à valeur qui sont communicables au sein de l’équipe.
Quelle valeur métier pouvez-vous apporter même avec quelques tests?
Joel Oliveira
En note personnelle, mesurer le temps additionnel généré par l’automatisation sur les étapes d’analyse de faux positifs, rework et maintenance.
Cela vous permettra d’avoir une vue factuelle de l’effort d’automatisation et de sa possible optimisation.
Dans tout système une action à un effet contre-balancier nécessaire d’appréhender pour maîtriser les mécanismes mis en place.
Concrètement:
- Si vous deviez choisir 3 tests à plus forte valeur, quels sont-ils?
- Pouvez-vous exécuter ces tests à la demande, rapidement et avec fiabilité?
- Leur valeur est-elle perçue par l’équipe avant d’aller plus loin?
La valeur est dans l’utilisation des tests, la rapidité d’exécution est souvent clef
Nous avons ici partagé un cas concret : des tests exécutés la nuit car trop longs en journée et non utilisés par leur équipes.
Sont-ils en fait vraiment utiles même la nuit? À priori très peu dans le contexte partagé, étant des tests fonctionnels. Les équipes auront tendance à les délaisser.
La valeur de l’automatisation de tests ne se limite donc pas seulement au gain de temps, mais également à son utilisation réelle.
La rapidité d’exécution des tests automatiques augmente la valeur pour l’équipe.
Antoine Craske
Les pratiques d’industrialisation type CI/CD peuvent aider à favoriser leur usage, le besoin de rapidité d’exécution reste néanmoins fort.
Pragmatique il convient donc de :
- Choisir un périmètre raisonnable de tests à automatiser
- Définir une solution pour paralléliser les tests les plus récurrents
- Mesurer que le temps d’exécution reste en dessous du seuil fixé
Les autres tests automatisés, moins récurrents, peuvent être par exemple découplés du cycle de validation court, tout en fournissant des alertes.
Les tests ont besoin de conception comme tout autre activité d’ingénierie
La maintenance des tests automatisés est souvent un défi pour les équipes.
On relate souvent une mise en place longue, en chambre, d’une suite de tests automatiques, qui suite à un changement du produit tombe complètement en erreur.
Malheureusement, s’ils sont contournés à ce moment-là, très probablement la suite de tests sera oubliée et l’investissement perdu.
Dédier du temps à la conception des tests est un investissement en valeur à moyen et long-terme.
Antoine Craske
Dans l’hypothèse qu’un périmètre raisonnable de tests soit automatisé, le manque de modularisation et de découplage est une cause récurrente.
Ces problématiques sont communes dans d’autres pratiques d’ingénierie, d’où la criticité des activités d’architecture et de conception.
Souvent survolées dans un projet d’automatisation, la conception se révèle fatale à un moment où les tests auraient pu montrer leur valeur.
Appliquer des tests de test modulaire permettent par exemple d’identifier les composants communs.
Les questions que vous pouvez adresser :
- Existe-t-il un plan de test clairement défini, priorisé et aligné avec le métier?
- As-t-on défini des étapes claires de conception, validation et de refactoring des tests?
- Est-ce que la modularité et le découplage des tests a été explicitée?
Avoir une démarche incrémentale sur des fondations stables
On associe parfois projet d’automatisation de tests à un cycle en V qu’on peut facilement rationaliser et intégrer une fois terminé.
La réalité est bien différente, les tests étant liés à la validation d’un produit normalement en évolution, ils doivent accompagner ce rythme.
Les problématiques de maintenance sont aujourd’hui majoritairement pilotées par une bonne conception de tests, demain améliorés par de l’intelligence artificielle espérons-nous,
Au vu de ces différents éléments et de notre partage, une approche incrémentale et itérative nous paraît la plus adaptée.
Poser tôt des fondations avec une intégration bout en bout permet de valider rapidement des hypothèses structurantes sur le processus.
En utilisant le processus de manière journalière, on peut itérer sur le processus pour maximiser sa valeur en adaptant rapidement le processus.
Personnellement, il convient de garder dès le départ une vision des objectifs à atteindre de la conception et de l’organisation, comme nous le rappelle Stephen R. Covey dans cette citation.
Begin with the end in mind.
Dr. Stephen R. Covey
Les itérations doivent permettre d’amener une équipe à un bon port, pas oú le vent nous mène.
Ce que vous pouvez appliquer dans votre contexte :
- Quel est votre MVP applicable à tout le cycle de développement?
- Quelles fondations minimales sont nécessaires?
- Pouvez-vous simplifier l’intégration et le déploiement initial?
L’importance de la formation des équipes à la qualité
Seriez-vous en confiance pour une opération par un anesthésiste non formé?
Pourtant, c’est la réalité de la plupart des organisations qui confient la qualité de leur opérations à des profils non formés, ou laisse l’anesthésie au chirurgien dans notre métaphore.
Antoine Craske
Joel nous a remonté l’importance des compétences de qualité, et la difficulté à obtenir des réponses pertinentes en entretien.
Malheureusement les exemples de profils n’ayant pas le recul sur le contexte et techniques de test ne manquent pas.
Combien de fois avez-vous déjà entendu “On continue dans la même logique de ce qui existait”.
Il est important de comprendre le passé, d’apprendre de l’expérience, il reste néanmoins à être sûr de la pertinence des pratiques dans le contexte actuel.
C’est ici que des profils expérimentés et avec les bons réflexes auront le jugement et l’esprit critique adéquat pour s’adapter le cas échéant.
Le point est d’investir dans ces compétences :
- Faire reconnaître la valeur de la qualité dans l’organisation
- Assumer la QA et le QE comme une practice à part entière
- Dédier un investissement à la formation et amélioration continue..
La qualité est une responsabilité transversale que l’équipe doit composer
La qualité comme une responsabilité partagée de toute l’équipe avec un commitment global est l’un des sujets également abordés.
Néanmoins, le propos reste à balancer entre être la seule responsabilité de la QA, et être celle de tout le monde et de personne à la fois.
Par le partage d’expériences, un rôle d’animateur, coach et d’enabler dans l’équipe autour d’objectifs communs de qualité nous semble nécessaire.
Quant aux tâches d’automatisation, elles ne doivent pas forcément être faites par les testeurs ou développeurs, l’adaptation au contexte reste clef.
La présence de compétences est un différenciant dans un projet de ce type, qu’elles soient internes ou externes, durables ou ponctuelles par de l’expertise par exemple.
Ce dernier point rejoint le premier de prise de conscience métier : la qualité peut et doit être un investissement apporteur de valeur à l’organisation.
Concrètement, ces étapes doivent être évaluées :
- Quelles compétences de tests et qualité avez-vous idéalement besoin pour votre projet ?
- Pouvez-vous former vos équipes, accélérer avec des compétences externes?
- Comment pouvez-vous défendre un budget à moyen-terme pour ce besoin?
Des pratiques transverses pour réussir un projet d’automatisation
Au travers du partage d’expérience des différents membres de l’événement, beaucoup de sujets relèvent de pratiques transverses.
La clarification du besoin métier avec un engagement de toute l’équipe sur la qualité est un prérequis fort.
Une démarche incrémentale basée sur une conception solide et mise en place sur des cycles courts dans le cycle de vie fera la différence.
Les itérations suivantes doivent ensuite permettre d’adapter l’automatisation pour qu’elle apporte les bénéfices identifiées et qu’elle reste de valeur.
Par exemple, se focaliser à avoir peu de tests utilisés et rapides sera plus utile que de mettre en place 100 tests supplémentaires exécutés la nuit que l’équipe ignore.
J’espère que ce retour d’expérience vous aura été utile et concret, j’espère pouvoir échanger avec vous lors d’un événement ou continuer la discussion dans les commentaires.