La décision est prise, « nous allons attaquer notre dette test ». Cela semble positif, mais en même temps, nous nous demandons : « pourquoi en sommes-nous arrivés là ? ».
La dette de test est un gaspillage que les organisations doivent continuellement prévenir et éliminer pour maintenir leur vitesse et leur réactivité. L’enjeu est d’alléger l’effort de chaque changement, qui sinon, s’accompagne d’un poids supplémentaire ralentissant la livraison du logiciel au global.
Au cours de la table ronde « Oubliez la dette de test : créez des tests à valeur ajoutée », nous avons partagé la définition et les principales raisons de la dette de test avant d’identifier les bonnes pratiques pour des tests automatisés contenant la dette de test. Ce premier article se concentre sur la dette de test, le suivant est quant à lui dédié aux pratiques.
Je remercie chacun des participants pour leur participation et leur contribution :
- Joel Oliveira, Software Testing & Quality Assurance Evangelist, Public Speaker, Trainer, Senior Program Manager, Independent Consultant
- Rafael Amaral, Senior Software Engineer in Test chez Farfetch
- Filipa Nogueira, Engineering Team Lead chez La Redoute
Tout d’abord, commençons par explorer Test Debt avec un exemple concret.
Qu’est-ce que la dette de test ?
Une entreprise juge trop lente son itération de changements logiciels. L’automatisation des tests est identifiée comme une priorité pour accélérer les cycles. Un framework est rapidement construit pour automatiser le test manuel existant et produire des gains précoces. Puis des problèmes commencent à apparaître.
La précipitation a conduit à une suite de tests automatisés peu satisfaisante : de nombreux tests sont exécutés avec lenteur et instabilité, tandis qu’il reste difficile de mettre en œuvre certains tests manuels. De plus, la seule personne connaissant le framework de test va quitter l’entreprise. Vous consultez les tests pour essayer d’aider mais ils sont trop techniques et difficiles à comprendre.
Vous espériez de bien meilleurs résultats. Une suite de tests automatisés rapide et fiable sur les tests les plus importants pour l’équipe. Un framework connu, maintenable par d’autres personnes ou un éditeur. Un rapport de performance natif aligné sur les objectifs et les mesures de l’équipe.
La dette technique est : la valeur attendue de l’actif – la valeur réelle du système.
La dette technique et la dette test partagent les caractéristiques communes d’être un écart entre une valeur attendue et réelle. La dette de test peut être due à l’absence d’actions spécifiques ou être le résultat de décisions particulières. Il est important de garder ces deux typologies à l’esprit car, contre-intuitivement, l’inaction et l’action mènent à la présence de dette.
La présence de la dette test nous conduit à la question suivante, pourquoi en sommes-nous arrivés là ?
Pourquoi nous retrouvons-nous avec une dette de test ?
Nous pouvons commencer par regarder hors du monde des logiciels et des tests, en particulier dans celui de la finance, réutilisant notre analogie. Pourquoi tant de gens se retrouvent-ils dans une situation de dette financière ? Des raisons courantes sont communes pour la dette de test.
Une première raison est est liée aux deux éléments de mesure de la dette de test, celle « attendue » et celle « réelle ». La valeur attendue signifie qu’elle a été définie, partagée et convenue. Malheureusement, les attentes de qualité ne sont pas encore des réflexes d’exercices collaboratifs, comme celui de Shift-Up . La valeur « réelle » réside dans une caractéristique de la dette de test : elle est difficile à mesurer.
« La chose délicate à propos de la dette technique est que contrairement à l’argent, elle est impossible à mesurer efficacement. »
Martin Fowler, martinfowler.com
La dette financière se mesure facilement ; vous devez une somme d’argent spécifique à une entité. Pour la dette technique et de test, c’est moins facile. Vous pouvez utiliser les attributs de qualité des tests, des modèles de dette technique et des liens vers des indicateurs essentiels. C’est une première étape. Leur technicité et leur manque d’alignement avec les priorités de l’entreprise peuvent les rendre difficiles à comprendre pour les autres.
Un autre facteur clé réside dans un cocktail de 3 facteurs dangereux :
- Focalisation sur le court terme
- Manque de compréhension
- Boucles de feedback retardées
Les approches court-termiste se font au prix d’un endettement et d’effets secondaires à moyen terme. Les parties prenantes peuvent pousser dans cette direction pour atteindre des objectifs spécifiques, montrer leur pouvoir, ou tout simplement ne pas être conscientes des compromis. C’est notre deuxième facteur du manque de compréhension. Notre travail en qualité est d’exprimer les conséquences associées de choix spécifiques. Ne pas le faire nous mène au troisième facteur, les boucles de feedback retardées, difficiles à anticiper pour les humains.
Nous pouvons faire une analogie avec une situation courante dans le comportement humain. Un enfant commence à manger des bonbons. Il se sent bien, il en mange plus. Personne ne lui a parlé des impacts des bonbons au fil du temps sur le corps, l’esprit, etc. Les enfants s’en moquent car étant jeunes, son corps traite rapidement le sucre, il n’y a pas de problème à court terme. Au fil du temps, il commence à prendre plusieurs kilos jusqu’à ce qu’il atteigne un état critique d’obésité et doive se faire opérer.
C’est ainsi que ces 3 facteurs combinés conduisent les organisations à se heurter à un mur, quand elles deviennent incapables d’apporter des modifications logicielles. Elles doivent ensuite mettre en œuvre des changements drastiques si elles peuvent survivre. La dette de test ne se produit pas du jour au lendemain. C’est l’accumulation des décisions prises et non prises par un ensemble d’acteurs au sein de l’écosystème.
Nous avons identifié une pratique essentielle en s’appuyant sur l’ intuition et les données, les signes avant-coureurs.
Quels sont les signes avant-coureurs d’une dette technique de test?
La dette de test est difficile à mesurer dans les faits, mais nous pouvons compter sur notre capacité humaine à détecter, ressentir et réagir aux signes avant-coureurs. Pour l’automatisation des tests, nous pouvons détecter les comportements organisationnels et les attributs spécifiques d’automatisation des tests.
Revenons au Pourquoi de nos tests automatisés. L’un des objectifs de notre effort d’automatisation des tests est d’accélérer la livraison des modifications logicielles en toute confiance. La valeur d’automatisation de test disparaît lorsque l’équipe commence à contourner la campagne d’automatisation de test, à rechercher des chemins alternatifs, à demander des exceptions. Diverses raisons sont possibles comme un temps d’exécution long, une instabilité, un manque de compréhension ou d’autres critères de maintenabilité.
Le temps d’exécution est directement lié aux indicateurs essentiels de la livraison du logiciel : lead-time, cycle-time et MTTA. Ces mesures font toutes partie du rapport Accelerate, corrélant les performances de l’organisation avec ces mesures. Nous devons contraindre notre temps d’exécution de test pour limiter son impact sur ces métriques d’accélération. Pour l’automatisation des tests, cela signifie des tests moins nombreux, maximisant la valeur, exécutés plus rapidement. Il peut aussi s’agir de découpler les tests à exécuter sous un certain périmètre au lieu de lancer à chaque fois une large campagne de régression de bout en bout.
Le deuxième facteur d’instabilité du test, également connu sous le terme de flakiness, est mesuré avec le flaky ratio. L’instabilité n’impacte pas uniquement le test. Cela a un impact direct sur la confiance de votre équipe à délivrer du logiciel. Il est donc essentiel de viser ce pourcentage pour 100 %. Lorsque ce n’est pas le cas, en comprendre et corriger les causes profondes est une priorité. L’instabilité peut être mesurée lorsque vous avez mis en œuvre au moins un test automatisé, vérifiant sa stabilité dans le temps. Lors de l’ajout de tests, vous pouvez également commencer à mesurer la stabilité globale de la suite de tests.
Le dernier facteur se concentre sur les signes avant-coureurs de la maintenance des tests automatisés. La clé est d’agir tôt sur des indicateurs et des comportements spécifiques. Évaluez régulièrement l’impact du test automatisé en posant la question « Quel est son impact ? ». Elle vise à confirmer que les tests automatisés ont une réelle valeur et importance dans votre contexte. Êtes-vous capable de montrer une corrélation? Si vous entendez des phrases comme « Je ne comprends pas ce que fait la QA de toute façon », c’est un signal faible. L’équipe peut se perdre dans des optimisations techniques.
Le danger du manque d’alignement est celui d’une optimisation locale au détriment du système global. Il est dangereux de laisser une équipe d’assurance qualité se concentrer sur des larges rework, optimisation du framework et refonte des tests. Ils commencent à prendre l’habitude d’optimiser leur périmètre local sans nécessairement apporter de la valeur au reste de l’équipe. Ce type de comportement conduit à favoriser des techniciens satisfaits oubliant complètement le véritable objectif de leur travail. Traité trop tard, on entendra « Il vaut mieux commencer un nouveau framework, celui-ci est devenu trop complexe ». Cela nous conduit au sujet de la conception des tests.
Les tests automatisés nécessitent une conception comme toute activité d’ingénierie. Un certain nombre d’écueils doivent être évités, comme copier les tests d’une suite manuelle ou laisser les tests tels quels créés par un recorder. Vous pouvez décider d’utiliser certains de ces outils une fois les travaux préliminaires d’architecture, de conception et de modularisation réalisés. La conception des tests consiste également à sélectionner les tests à ne pas implémenter, une typologie de test importante à clarifier dès le départ.
La tendance de ces symptômes est celle du déséquilibre. C’est lorsque l’équation coûts/bénéfices n’est plus satisfaisante.
Adresser la dette de test avant qu’il ne soit trop tard
Les parties prenantes sont des personnes qui investissent de l’argent pour deux raisons, pour gagner ou arrêter de perdre de l’argent. Cet investissement peut s’arrêter lorsque la dette de test atteint un écart inacceptable entre la valeur réelle et la valeur attendue.
“La dette de test ne se crée pas du jour au lendemain. C’est l’accumulation des décisions prises et non prises par un ensemble d’acteurs au sein de l’écosystème.”
Antoine Craske
Nous voulons tous éviter cette situation. Les raisons conduisant à la dette de test clarifie que les multiples facteurs ne sont pas dus à une seule personne, équipe ou problème. Une approche plus intégrée et progressive est nécessaire.
Nous couvrons cette approche dans l’article suivant sur l’automatisation des tests avec le Quality Engineering.