suivantes :
- « la qualité de nos développements n’a pas augmenté́ »
- « la maintenance de ces tests est impossible »
- « ils prennent beaucoup trop longtemps à s’exécuter »
Pourquoi les équipes qualité mettent-elles en place des tests end-to-end ?
La réponse immédiate peut paraître simple : Un effet Fordisme* de séparation des responsabilités, une approche autonome facile, un “quick-win”. Cependant, c’est une approche pleine de bonne volonté de la part des QA. En repartant d’une question “provoc” : pourquoi y a-t-il des QA sur les projets agiles ? Soit parce que personne ne s’est re-questionné depuis les cycles en V** et il a été plus commode de garder l’organisation actuelle dans la plupart des entreprises ayant de l’âge. Soit parce que l’équipe de développement n’arrive pas à rassurer quant à la qualité de son livrable. Soit les deux.La pyramide de tests donne toutes les réponses à l’échec des stratégies end-to-end (e2e) massives. Premièrement, elle permet de comprendre une rupture claire dans le cycle de développement, avec une notion de “déploiement” : Dans le cycle de développement, deux sous-parties sont analysées :
- Le bas de la pyramide : en tant que développeur, les tests unitaires sont lancés en local jusqu’aux tests de composants, de manière isolée. Dans un écosystème backend Java et frontend TS, on aurait du JUnit, du Cucumber, du Jest, du Cypress.
- Le haut de la pyramide : tous les composants déployés sont nécessaires, c’est lorsqu'un push est fait sur une MR/PR que l’histoire commence. Les e2e vont se lancer soit sur la MR/PR, soit au merge, soit une fois par jour... dans tous les cas, c’est hors “local”, et ici commence le premier biais.
On a tendance à ainsi épouser la séparation des responsabilités qui en découle :
- Les devs s’occupent d’améliorer la qualité du code, ce qu’on ne peut pas toucher car c’est leur repo de code, leur workflow en local.
- Les QA s’occupent des environnements déployés : lancement d'un chantier de tests end-to-end.
En transition, traiter “la qualité” sans tenter de définir ce que le mot vient abstraire, c’est oublier une belle partie de l’histoire : la maintenabilité et l’évolutivité. La maintenabilité est l’aptitude à maintenir le produit en état de marche, à moindre coût. L’évolutivité est l’aptitude à poursuivre les améliorations sur le produit, tout en maîtrisant un coût à hauteur de la valeur apportée, autrement dit en limitant ces coûts.
Venons-en à ce coût :
Plus on monte dans la pyramide de tests, plus les tests couvrent de fonctionnalités et de liants technologiques. Un test end-to-end va donc couvrir directement une grande partie fonctionnelle, et par effet de bord, la bonne communication entre tous les composants technologiques : la connexion à la base de données, les ouvertures réseau, l’authentification sur une API, une partie du contrat entre le frontend et le backend [...] Ils semblent délicieux de prime abord ! Et c’est plutôt vrai, dans la modération. Manger un Paris-Brest rend ravi, en manger 72 d’une traite provoque une émotion différente…À mesure que l’on monte dans cette pyramide, il devient de plus en plus complexe d’écrire et de maintenir les tests. Un test unitaire s’écrit en quelques secondes. Un test de composants en quelques minutes, en ciblant souvent des appels API ou de services. Un test e2e prendra quelques dizaines de minutes voire de l’ordre de l’heure, en ciblant un parcours utilisateur. Ces temps sont très dépendants du contexte et des exemples existants, l’ordre de grandeur est le jour dans de nombreuses organisations.
Imaginez une stratégie visant à couvrir toutes les règles métier, leur combinatoire, et les tests aux limites par cette typologie de tests ? Le temps d’écriture serait abominable, mais le temps de maintenance serait pire. Il faudrait attendre la fin du déploiement pour corriger les erreurs. Toute l’organisation perdrait un temps monstrueux dans des allers-retours entre du code local et un environnement déployé.
Alors si 72 end-to-end ne sont pas écrits, à quoi servent les QA ? Et si le rôle des QA n’était pas d’être des héros de la qualité mais des coachs et des accélérateurs de la qualité ?
Comme la culture DevOps enseigne que les ops doivent être au contact des équipes dans le quotidien, non pour “faire tout seul” mais pour “faire ensemble”. Comme Scrum enseigne que les Scrum Master sont des facilitateurs de l’agilité, accompagnant leurs équipes dans l’adoption de pratiques agiles.
Il semble essentiel que de nombreux QA réinventent leur rôle : au sein des équipes, coachant la pyramide de tests, le TDD, la boucle de feedback, acquérant les compétences techniques nécessaires pour bootstrapper la mise en place de Cucumber et de Cypress qui est souvent un véritable frein pour les équipes, accélérant la mise en place de tests de composants par exemple en pair-programming ou mob-programming avec les devs.
Se tournant également vers les Product Owner pour faciliter l’émergence d’une compréhension unifiée des concepts au sein du produit et de l’équipe, par exemple avec un langage omniprésent. Il reste donc une belle marge de manœuvre pour couvrir ce mot “qualité”.
L'analogie avec le Mikado et le Jenga
Les jeux de Mikado et de Jenga illustrent bien les défis des applications informatiques et les sentiments qu’ils provoquent chez les développeurs : le challenge, la crainte, l’absence de contrôle, l’échec. Les katas de code sont des moyens efficaces pour aborder ces problèmes, car, comme dans le Mikado et le Jenga, ils sont déconnectés de la production, de la pression négative et des coûts. Le Mikado est particulièrement pertinent en relation avec la charge cognitive théorisée par John Sweller, la mémoire de travail gérant une quantité limitée d’informations.Imaginer que faire bouger un Mikado nécessite une réunion de crise pour comprendre l’échec, tracer un ticket d’incident, ou recevoir une critique par courrier, illustre la complexité et le stress inhérents aux environnements de développement.
Des expériences ont montré que les coûts de correction des bugs sont souvent de 10 % des coûts de build, et que les coûts de maintenance représentent en moyenne 70 % du budget de développement, contre seulement 30 % pour les nouvelles fonctionnalités. En outre, 45 % des fonctionnalités informatiques ne sont jamais utilisées.
Vers une meilleure gestion des bugs
Il est courant de voir des organisations où une personne est dédiée au “run” (traitement des incidents, bugs, déblocage des clients). Les équipes mettent en place des rotations pour se répartir la charge, motivant ainsi la nécessité de s’attaquer à ce fatalisme. Tendre vers zéro défaut peut sembler utopique, mais il est temps d’adopter des recettes de cuisine en informatique. L'analogie culinaire souligne l'importance d'une approche structurée et rigoureuse, tout comme la gastronomie repose sur des techniques et des ingrédients de qualité pour des résultats fiables et savoureux.Par Cédric Magne, Practice Leader Software Engineering des équipes chez Ippon Technologies
