Le ROI, je t’aime moi non plus

Benjamin Butel nous partage sa perspective sur le fameux ROI de l’automatisation en contexte de qualité logicielle dans cet interview de la QE Unit.

Benjamin intervient en tant que coach agile et test avec une approche et organisation orientées produit. Sa priorité est la création de valeur supportée par des démarches itératives.

Cet interview est dédiée au ROI (Return On Investment) d’automatisation, une question qui peut énerver sans contexte, comme une bouteille jetée à la mer. Ce sujet soulève néanmoins de vrais questionnements.

Ce partage nous amène à prendre du recul via une perspective d’entreprise, du métier et de ses clients se recentrant sur les bonnes questions et processus à suivre.

Rejoignez la QE Unit pour accéder à du contenu exclusif et régulier de la communauté.

À propos de Benjamin Butel

En tant que coach de test, je prends plaisir à élaborer des stratégies de test intelligentes pour les problèmes de projets logiciels. J’aime également conduire l’équipe de test et l’aider à améliorer ses compétences en test et à lui donner confiance en sa capacité à toujours faire de son mieux de manière simple et amusante.

Je suis également convaincu que la communication est la meilleure clé pour l’amélioration, les réussites personnelles et professionnelles. Organisateur des meetups du Ministry of Testing Rennes, membre du MForTest, Organisateur de la Paris Test Conf.

Antoine : Peux-tu commencer par te présenter?

Je suis Coach Test chez Klaxoon, société française qui produit un logiciel axé sur la collaboration d’entreprise. Une de mes passions est le test logiciel, j’aime au-delà de mon rôle participer au Ministry of Testing de Rennes. Depuis le confinement, nous organisons des événements en ligne couvrant toute la France qui nous ont permis d’avoir de bons échanges.

Je participe également à l’organisation de la prochaine édition de la Paris Test Conf. Dans les dernières années, j’ai également partagé ma perspective du testing au travers d’articles sur la taverne du testeur.

Antoine : Un sujet a tendance à particulièrement t’agacer dans le domaine du test et de la qualité logicielle, tu peux nous en dire un peu plus ?

Depuis quelque temps, je vois régulièrement passer des messages sur le calcul du ROI de l’automatisation. Ce qui m’agace en premier est l’absence de contexte rendant difficile d’articuler une possible réponse. Surtout, cela pose pour moi la réelle question qui n’est pas posée : “Pourquoi ?”.

Pourquoi vouloir calculer un ROI ? Quel est l’objectif derrière ce calcul de ROI ? La question tire le pourquoi de l’automatisation. Cela amène à une réflexion que je ne vois pas émerger, on reste focalisé sur ce sacre de l’indicateur et du gain financier. À titre personnel, je pense que c’est inutile, particulièrement en agilité.

Antoine : Quelles notions vois-tu pertinentes en lien avec l’agilité ? Est-ce la notion de valeur, différente de celle de la qualité ou de celle des tests ?

C’est bien la notion de valeur. Si on essaye de répondre au pourquoi de l’automatisation par un “Aller plus vite sur ma phase de recette”, c’est pour moi un carton rouge. Cela n’a pas de sens. La vraie question est “Pourquoi vouloir aller plus vite dans la phase de recette ?”. Si on s’oriente vers un besoin d’accélération, on a déjà un premier élément de réponse. Il reste à identifier ce qu’on voudrait livrer plus vite, quelles fonctionnalités, pourquoi, etc. Sans faire l’exercice jusqu’au bout, on va itérer jusqu’au fondement initial du travail réalisé, son sens, sa valeur. Le point départ est bien la valeur que l’on veut apporter, et pour qui.

“Le point départ est bien la valeur que l’on veut apporter, et pour qui.”
Benjamin Butel

Si on initie maintenant notre réflexion à partir de la création de valeur, nous pouvons évaluer en quoi l’automatisation peut nous aider. La pertinence d’un ROI est questionnable pour cet exercice, en quoi va t-il nous aider à mesurer la valeur ? Est-ce que le calcul du meilleur coût est réellement l’équation à poser ? C’est ici que la bât blesse pour moi, on prend le sujet à l’envers en démarrant par le ROI.

Antoine : L’approche ROI nous positionne effectivement en bout de chaîne à faire un calcul de temps gagné sur des tests manuels versus automatisés par exemple. L’automatisation est-elle au service de la création de valeur, qui elle doit être mesurée ?

L’automatisation pour moi est un outil, comme le test. Je vais même aller plus loin, la production logicielle n’est qu’un outil. Mis à part quelques sociétés spécialisées en édition logicielle dont l’outil est leur métier, le métier n’est pas l’outil que l’on développe. Si on prend les outils qui supportent le métier de la banque, le métier est bien de faire celui de banquier, supporté par des outils permettant d’accélérer et d’améliorer ce métier. Dans cette perspective, l’automatisation n’est qu’un outil parmi d’autres pour contribuer à la création de valeur.

Le calcul d’un ROI d’automatisation de 25 sur 50 cas de tests manuels nous ferait penser qu’on va gagner au moins la moitié de notre temps. Le prisme est erroné, sans parler du temps supposé “gagné” que l’on va passer à maintenir nos tests. Je m’interroge beaucoup sur la pertinence de ce ROI, manifestant un manque de recul des organisations. J’ai d’ailleurs du mal à comprendre pourquoi.

“Si l’on répond bien au “pourquoi” et au “pour qui”, le ROI n’est pas le sujet.”
Benjamin Butel

Certes, l’automatisation peut apporter un facteur de confiance, à la limite. Mais si l’on répond bien au “pourquoi” et au “pour qui”, ce n’est pas un ROI qui va supporter nos prise de décisions et priorités à adresser. Dans tous les cas, un ROI seul ne permettra pas de piloter la production de valeur. Des indicateurs doivent plutôt être posés pour mesurer l’apport de valeur suite aux changements et itérations que nous réalisons.

Nous devons en fait répondre à deux questions pour piloter la valeur créée “Comment mesurer la production de valeur ?” et “Comment mesurer que nous la produisons mieux?”. Le ROI ou l’automatisation ne me semblent pas être les bonnes réponses systématiques à ces questions. On peut vite tenter de répondre au mauvais problème sans la bonne perspective. Un exemple est de vouloir aller plus vite dans nos itérations, compensant des mauvaises organisations en amont. On gagnera peut-être quelques heures en aval, au détriment des jours perdus en conception et alignement initial.

Antoine : Notre priorité est donc la production de valeur via un système organisationnel performant, itérant et améliorant la création de valeur. As-tu des pistes de mesure de cette valeur ?

Des outils de satisfaction client sont un bon point de départ pour mesurer la qualité d’un produit. Nous pouvons également utiliser le taux de transformation, la satisfaction des divers utilisateurs du produit; nous en revenons au métier supporté par les outils. L’automatisation peut être l’un des éléments pour accélérer, faciliter ou mieux réaliser ce métier. On oublie d’ailleurs facilement les facteurs humains de confort, d’utilisation, qui peuvent au contraire nécessiter de ralentir.

Les indicateurs sont donc très contextuels, ils sont dépendants de chaque contexte, entreprise et métier.

Nous pouvons ensuite travailler l’alignement du produit, de la suite logicielle et même du système d’information à construire face à ces indicateurs de valeur. C’est ici qu’entre en jeu les indicateurs mesurant l’adéquation du système organisationnel à la création de valeur. Il n’y a qu’en partant de la raison d’être du produit que nous pouvons trouver les bonnes organisations, outils et processus.

“Il n’y a qu’en partant de la raison d’être du produit que nous pouvons trouver les bonnes organisations, outils et processus.”
Benjamin Butel

Forcément, au début, il n’y a pas de miracle, nous partons d’un état donné, avec ses avantages et inconvénients. C’est de ce point de départ que nous devons mesurer l’amélioration progressive de la création de valeur par itérations. Calculer le ROI des tests automatisés n’apportera pas d’intérêt sur l’identification de cette meilleure production.

Il n’est pas nécessaire d’avoir un ROI pour initier une démarche d’automatisation. On peut identifier un scope d’automatisation minimal, explorer la pertinence et la création de valeur avec l’équipe. À partir de premières itérations, on peut mesurer l’apport de valeur. On peut se rendre compte qu’on gagne ou perd du temps, même si le focus doit rester sur la valeur, propre à chaque contexte.

“Il n’est pas nécessaire d’avoir un ROI pour initier une démarche d’automatisation.”
Benjamin Butel

Si l’on se place dans un contexte agile, l’une des grandes forces de l’automatisation est la confiance apportée à l’équipe durant les cycles de développement. Un calcul du ROI comparant test manuel versus automatique n’a pas de sens dans ce contexte, la priorité étant de construire le produit permettant de créer la valeur. L’équipe doit répondre collectivement à la question du “Comment”.

Comment s’organiser? Comment y intégrer la qualité? Les tests automatiques, exploratoires ne seront finalement que des outils pour injecter la qualité dans cette production. En sortie, nous livrons un produit avec son écosystème de solutions sur lequel nous pouvons mesurer sa valeur et ses axes d’amélioration. On peut mesurer du ressenti, du factuel, par exemple du taux de retour arrière, d’anomalies. Mais j’ai vraiment du mal à comprendre l’intérêt de calculer un ROI avant même d’avoir automatisé quoi que ce soit, et pour quoi faire.

Mon message est d’essayer. Si l’équipe pense qu’une pratique peut améliorer leur production de valeur, elle peut décider de tester leur hypothèse sur un petit périmètre au prochain sprint. Si de la valeur est effectivement créée, l’équipe peut continuer, ou au contraire, sans valeur, s’arrêter de suite pour évaluer d’autres pistes.

Antoine : Une approche de l’automatisation focalisée sur les tests s’écarte donc du véritable sujet de production de valeur ?

J’ai le sentiment que le ROI s’apparente beaucoup à la notion de gain financier. Quand j’ai eu affaire à cet indicateur, c’était pour atteindre des objectifs financiers ou contractuels complètement démesurés.

Un premier cas était de vouloir mesurer quel gain entre l’automatisation de 80% ou 100% des tests existants. Un autre est celui de la couverture de tests à 60% par défaut, sans même une notion de périmètre couvert. Que veut dire ce 60% ? Quel lien avec la valeur ? Ce qui m’intéresse est la production de valeur, la rapidité d’obtention de feedbacks et la confiance de l’équipe.

Antoine : Cela remonte un sujet culturel de la perception de valeur de la qualité par les organisations. On pense que la qualité nous fait gagner de l’argent par l’automatisation seule, loin de création de valeur. As-tu le même sentiment ?

Oui, tout en ayant la sensation que c’est une vision plutôt française de la qualité. En regardant mes homologues anglo-saxons ou outre Atlantique, j’ai le sentiment que le prisme n’est pas le même.

Il n’y a qu’à regarder des gens comme John Ferguson Smart, Lisa Crispin ou Janet Grégory. Quand on les suit, on retrouve les mêmes sujets mis en avant : la valeur, le produit et les intéractions humaines. Les outils sont ensuite des mécanismes qui peuvent certes accélérer les choses, faciliter la vie, mais leur premier prisme est bien celui de la valeur. Aucun de ces éléments apparaît dans un ROI d’automatisation, et ne permet de tirer quelques types de conclusions.

Antoine : Que pourrais-t-on donner en guidelines quand on voit apparaître ces demandes de ROI ?

Pour moi il faut se poser les bonnes questions. Que la demande émerge, cela ne me choque pas, peut être en conséquence d’un réflexe managérial ou effet d’un cycle en V. Ce qui m’intéresse revient au “Pourquoi”. On retrouve ces éléments dans le livre de Lisa et Janet “Agile Testing Condensed” : le Why, le Who puis le How. Le calcul du ROI d’automatisation rentre dans le How, en troisième position. Je commencerais donc par le “Pourquoi” puis le “Pour qui” qui va amener au bon raisonnement.

“Commencer par le “Pourquoi” et le “Pour qui” amènera au bon raisonnement.”
Benjamin Butel

Si on veut gagner de l’argent et réduire l’équipe de testeur, je suis désolé pour vous, mais il vaut certainement mieux démissionner. Dès lors que l’on a quelque chose de programmatique, l’automatisation reste quand même sujet à maintenance, quoi qu’il arrive. Le logiciel vit et les outils doivent accompagner son développement et ses changements. L’agilité nous pousse également à être plus pragmatique en utilisant le bon outil au bon moment pour apporter de la valeur. J’ai donc beaucoup de mal à prédire un gain de valeur par l’automatisation.

Mon vécu m’a souvent montré que l’on dépassait rarement l’étape 1 ou 2 par rapport aux apports que l’on avait imaginé.

Antoine : On peut vite se faire un film sur l’achèvement ultime d’une architecture d’automatisation, quand une approche just-enough suffisait à l’apport de valeur.

Il y a des retours d’expériences réguliers d’Axa sur leur infrastructure de test. Ce serait intéressant de voir le positionnement qu’ils ont pu faire de cet investissement. Je ne vais pas parler pour eux mais j’imagine qu’ils y sont allés pas à pas, en mesurant la valeur apportée du système global au métier d’Axa plutôt que la mesure du gain de leur infrastructure de test. Je vous invite à consulter les derniers articles qu’ils ont poussé tant pour les résultats obtenus que la structure mise en place.

Si on se projette dans des organisations plus complexes, politiques, il sera compliqué de faire évoluer les mentalités dans ce contexte. La réponse ne doit pas être pour moi de ne pas faire le ROI; il faut du prendre du recul sur le “Pourquoi” dans le contexte, pour y donner du sens.

Peut être que dans l’interrogation nous allons trouver un point qui ne nous fera pas aller vers l’automatisation. Une idée plus bénéfique pourra émerger pour mieux répondre à la problématique identifiée. C’est souvent ce qui se passe dans les expressions de besoin, on arrive directement avec une solution. Il faut appliquer le même processus pour remonter dans la chaîne afin d’évaluer d’autres pistes.

Antoine : Je vois souvent une focalisation des profils d’ingénieurs sur les sujets purement techniques et technologiques. Ce que tu viens de partager est en fait la matérialisation du besoin de collaboration, d’empathie, d’écoute au cœur de la création de valeur ?

C’est ce qui est tiré par les différents rituels comme l’Impact Mapping ou l’Exemple Mapping où le focus est bien sur la collaboration. Il peut exister quelques outils collaboratifs pour aider dans un contexte distanciel. Cela me rappelle un tweet de Lisa nous disant de prendre un bloc-notes, de se mettre debout et d’aller partager ce que l’on imagine sur un tableau.

Je suis intimement convaincu que les échanges activent des mécanismes de collaboration beaucoup plus forts que des emails ou tickets. On est dans le manifeste agile avec “les intéractions humaines plus que les outils”; on place les outils et processus en support de ces mécanismes, sans les négliger ni être la première préoccupation.

Quand on commence à atteindre un bon niveau en collaboratif, on peut passer vers le collectif, passant un cran.

Le collectif abat des montagnes, il n’y a rien de plus fort pour moi. On peut être collaboratif sans être collectif. À l’instar d’une équipe de foot avec les meilleurs joueurs agissant individuellement, ils n’iront pas loin. En logiciel, on peut très bien réussir 4 ou 5 sprints, et complètement rater le sprint 6 par fatigue ou manque de collectif. Ce n’est pas le ROI ou l’automatisation qui va nous prémunir, ce sont des sujets humains, beaucoup plus difficiles à mesurer et à maintenir en cohésion.

Antoine : En complément de ce que l’on a échangé, as-tu des contenus, citations ou personnes qui t’inspirent ?

Au niveau international les livres de Lisa Crispin et Janet Grégory sont pour moi des références “Agile Testing” ou “Agile Testing Condensed”. On y retrouve des contenus et références au Visual Mapping et aux pyramides d’automatisation. Il y a aussi des choses intéressantes d’Alan Page sur le Modern Testing, comme le pilotage par la donnée.

Le livre “Le chaînon manquant” de Valentin Guerlesquin et Henri Bigot relate la transformation d’une équipe au sein d’un grand groupe. Je vais peut-être dire une bétise, mais je pense qu’il n’y a pas une seule fois le mot ROI dans ce livre ! Ce n’est pas ce que j’en ai retenu en tout cas. L’histoire est celle d’une équipe qui cherche à démarrer l’automatisation de tests, et comment elle y arrive par une approche transverse. Je le recommande vraiment sans vouloir faire de la “pub” à mes collègues; ça se lit très bien, sous forme romanesque, et peut aider les gens qui se posent des questions sur l’automatisation.

Petit teaser, J’en profite pour partager que le livre “Agile Testing Condensed” de Lisa et Janet sera bientôt disponible en version française ! Nous sommes en finalisation de relecture avec ma collègue Emna Ayadi pour une sortie imminente.