Je suis magiquement devenu plus intelligent. Pour cela j’ai passé une heure de brainstorming avec quelques brutes des tests d’acceptance. Le port du casque est obligatoire pendant la lecture de cet article, où je me suis laché.
Alors présentons quelques acteurs tout d’abord. Celui qui prend la parole avec un accent russe, c’est Gojko Adzic. Un gars très brillant qui m’a donné envie de lire son livre : « Bridging the Communication Gap, Specification by Example and Agile Acceptance Testing » auquel Eric Lefèvre-Ardant a participé. A côté de lui, un accent purement londonien, c’est Antony Marcano de Skills Matter. Ces gars sont forts. Le reste des quelques 30 personne est constitué de français, de quelques personnes de JetBrains et de Pulse, ainsi que d’autres personnes de ThoughtWorks.
L’objet du débat est de discuter pourquoi les tests d’acceptance échouent, et quelles sont les choses que l’on peut améliorer afin d’éviter cela.
Gojko liste quelques points qu’il a identifié lorsqu’il travaillait sur son livre, qui font que les tests d’acceptance ne sont pas mis en place sur un projet.
1) No collabortaion
2) Focusing on « how » and not on the « what »
3) Test unusable as live document
4) Expecting Acceptances Tests to be a full regression suite
5) Focusing on tools
A cela, nous ajouterons après une discussion un point 6:
6) When acceptances tests are not considered as a value added activity.
Par rapport au point 1, c’est assez facile à expliquer. Il est impossible de mettre en place des tests d’acceptance correctement, si votre client ou votre donneur d’ordre n’est pas impliqué dans l’écriture de ceux-ci. Pour rappel, pour ceux du fond qui ne suivent pas, un test d’acceptance est une histoire écrite sur un document électronique, que l’on peut transformer en test exécutable. Si par exemple j’écris:
« En tant qu’administrateur je veux créer un mot clé Devoxx sur la section Catégorie en remplissant une zone de saisie avec Devoxx et en cliquant sur le bouton valider. »
Un outil comme FitNesse permet ainsi d’écrire ce type de test et de les exécuter facilement en quelques minutes.
Gojko résume donc que les tests d’acceptance sont des spécifications. Si vous avez du mal à mettre en place une bonne collaboration, expliquez que vous travailler sur des spécifications, c’est simple.
Par rapport au point 2, nos discussions nous amènent à dire qu’il est important de travailler sur ce que l’on veut tester, pas sur comment. Pour cela, Gojko illustre son point avec l’exemple amusant de la fabrication du F-15 par l’armée américaine. Le militaire explique à un ingénieur les souhaits de l’armée américaine :
– « Nous voulons un avion capable de voler à 2.5 Mach pour 10 millions de dollars ».
Les industriels débutent les recherches, mais il s’avère rapidement impossible de construire un tel avion à cette époque, capable d’aller à 2.5 Mach. Et là le projet aurait pu s’arrêter. Mais un gars plus malin que les autres demande alors
– Pourquoi voulez-vous absolument un appareil capable de voler à 2.5 Mach ?
– Et bien pour qu’il vole plus vite que le Mig, qui vole à mach 2
– Il faut 25mn pour passer de mach 1.5 à mach 2.5, est-ce c’est acceptable pour vous ?
– Bien sûr que non ! Nous, ce que l’on veut, c’est un avion capable de bombarder, puis de repartir le plus vite possible sans se faire descendre par les Migs
– Votre besoin est donc d’avoir un appareil capable de battre en dogfight ce Mig alors ?
– Euh… oui… »
Après cette discussion, l’ingénieur leur propose de réaliser un avion pour 9 millions de dollar, qui ne volera qu’à 1.8 Mach mais qui sera bien plus agile que le Mig de l’époque. Il pourra donc gagner les combats aériens. Et c’est sa compagnie qui a remporté le marché… Le besoin était d’éviter de se faire descendre, pas de voler le plus vite possible.
Tout ceci pour vous dire que lorsque les clients vous demandent quelque chose, il faut absolument creuser leur besoin et il ne faut surtout pas commencer à coder sans avoir bien compris le problème à résoudre… Repensez au F15 la prochaine fois que votre BA vous demande quelque chose…
Les tests d’acceptance ne font pas tout de toutes les façons. ll est important de pouvoir s’en servir comme d’une documentation vivante de votre projet. Antony Marcano insiste sur l’importance de l’expressivité des tests, sur l’importance de la maîtrise de l’écriture naturelle lorsque l’on rédige des tests d’acceptance. La vraie documentation d’un projet, qui sera toujours à jours, c’est la liste des tests d’acceptance. Limpide, intelligent, j’aime.
Un souci rencontré est l’utilisation de ces tests pour faire de la non-régression. Moi le premier sur notre projet, nous utilisons FitNesse pour comparer des rapports financiers. Or bien qu’il soit évident que cela soit possible, ce n’est pas l’objet des tests d’acceptance. On verra plus loin l’importance de la communication entre les humains. Vous savez, ce gars avec une cravate qui vient chaque mois et que l’on vénère comme « LE CLIENT ». Et bien si votre chef de projet ne sait même pas comment il s’appelle, virez le chef de projet. C’est un incompétent.
Pour le point 5, il est important de ne pas se faire embarquer par les outils de tests fonctionnels. Allez, qui est venu voir un jour son product owner, a lancé FitNesse en réunion, et a annoncé fièrement au client qu’il fallait maintenant qu’il utilise cet outil ? L’outil ne doit pas être imposé à votre client, à votre MOA. Le plus simple c’est un tableau blanc et des crayons. Si quelqu’un de votre équipe peut écrire quelques tests pendant la réunion, c’est génial. Dites au client que vous êtes entrain de faire le compte-rendu de la réunion, ce qui est vrai, et écrivez correctement les différents points de validation sur votre page FitNesse. Vous ferez la plomberie plus tard.
Si un outil d’acceptance test n’est pas bon, ou que vous êtes bloqué, changez d’outil ! Ne dites pas au client que « cette partie on peut pas la tester avec FitNesse ». C’est simplement débile ! A vous de trouver d’autres moyens pour tester le logiciel et conserver le principe des tests d’acceptance.
Gilles de Valtech apporte aussi un point dans la discussion intéressant : les développeurs pensent que les tests ne sont pas aussi important que le code. Si les tests unitaires ne compilent pas, ou ne passent pas, souvent ce n’est pas grave. Si les tests d’acceptance ne sont pas mis à jour, ce n’est pas grave. Et il explique alors qu’un des soucis de l’adoption des tests d’acceptance, est cette mauvaise image que nous leur donnons. Il est important de considérer que le code des tests unitaires est aussi important que le reste du logiciel.
Un débat ensuite sur la perception des testeurs par le management. Et là il y a du travail… Les ingénieurs qualités sont mal perçus. Ils se retrouvent dans des équipes à part… « Ouais eux c’est les gens de la QA… ».
Et bien ce n’est pas bien.
Si votre qualité est pourrie, et que vos spécialistes de la qualité sont dans un congélateur au lieu d’être sur les genoux de vos développeurs, vous pouvez toujours attendre un miracle. Craftmanship over Crap comme disait Uncle Bob… vous vous souvenez de ce matin ?
Par rapport aux outils comme FitNesse, il est aussi important de se souvenir, que ceux-ci ne sont qu’une fraction de la demande du client. Prenez le jeu du « Telephone Drawing Game » qu’explique Antony. J’écris une phrase sur une feuille que je passe à mon voisin. Par exemple : « le chien chante à côté d’un Caddie ».
La personne suivante doit alors dessiner un petit dessin à partir de la phrase, plier la feuille pour masquer ma phrase et ne laisser que le dessin, puis ensuite faire passer la feuille à son voisin. Celui-ci doit écrire ce qu’il voit, plier la feuille pour cacher le dessin, et passer la feuille… et ainsi de suite.
Vous suivez ?
…
Bon allez voir là.
…
Et bien réfléchissez à ce qu’il se passe lorsqu’un client demande à un super fonctionnel qui demande à une MOA qui demande à un développeur de faire une superbe fonction… c’est juste impossible. Et pourtant c’est ce que l’on fait chaque jour non ?
Il faut placer de la valeur sur une réunion, où le client et le développeur travaillent ensemble. Prenez un tableau blanc, des crayons, des boissons fraîches, et faites bossez ces gens ensemble. J’aime beaucoup l’idée de retirer dans un premier temps ces inséminateurs d’intelligence artificielle que sont les petits gars de la MOA.
Si le client n’est pas disponible car trop important, trop rare, trop pas le temps de parler avec des développeurs, et bien tant pis. Antony explique qu’après tout, 40% des projets repartent en réécriture. Surtout lorsque les clients/décideurs changent…
Je pose la question suivante : quel lien pouvons-nous faire entre les éléments d’un product backlog et les tests d’acceptance ? La réponse est la suivante : les User stories ne sont que le scope de ce qu’il faut faire. Et c’est souvent volontairement, que l’on laisse une part de vague dans leur définitions. Par contre, les tests d’acceptance que vous devez définir lorsque la tâche débute, sont eux des éléments de validation. Enfin il faut se souvenir qu’en Scrum, c’est le client au final qui accepte ou non la fonctionnalité. Les tests d’acceptance sont là pour aider, mais ce ne sont pas des tests de recette !
Gojko rappelle le principe des 3C :
– Card,
– Confirmation and
– Conversation
Une carte cartonnée qui sert de fiche navette, une confirmation au dernier moment avec le client, ce qui permet d’écrire les tests d’acceptance et enfin une Conversation avec lui pour bien définir ce qu’il faut faire et ce qu’il veut. Repensez aux F15. Finalement ce n’était pas un avion rapide que le client voulait, mais un avion capable de ne pas se faire descendre par le Mig de l’époque. Et la vitesse n’était pas la solution au problème.
Pour terminer, nous avons rappelé l’importance du management dans ce processus. Il faut aligner tout le monde pour travailler ensemble. Une spécification ne fait pas tout, un analyste métier qui écrit une spécification et qui s’en lave les mains ensuite, c’est n’importe quoi. Un développeur qui commite son code et qui se fiche ensuite des tests ou de la mise en production, c’est n’importe quoi. Un chef de projet qui joue avec Microsoft Project mais qui ne sait pas comment s’appelle son client, c’est juste n’importe quoi.
Enfin la conclusion a été qu’il ne faut pas sous-estimer les efforts nécessaires pour mettre en place des tests d’acceptance. Cela entraîne des changements parfois violent, et il faut donc accompagner le changement. N’essayez pas d’imposer un outil comme FitNesse à vos clients ou vos équipes d’analyste. Ce que vous voulez imposer c’est un principe de fonctionnement, des règles de jeu. Pas la couleur du maillot ou la taille des cheveux.
En conclusion, une séance très intéressante qui donne envie de s’intéresser à ces fameux tests, pour améliorer la qualité de son travail. J’adopte !
Références
Blog d’antony
Blog de Gojko Adzic
On dit « FitNesse » et non « fitness » 😉
« Be-monster not thy feature, wer’t my fitnesse »
Shakespeare, King Lear »
C’est corrigé, merci.
Salut Nicolas,
chouette résumé 🙂
Par contre je vais décevoir, ce n’est pas moi qui ai parlé du point intéressant sur le manque « d’amour » pour le code de test. Je suis plutôt coupable des points 6 et 8 dans le résumé de Gojko (http://gojko.net/2009/09/24/top-10-reasons-why-teams-fail-with-acceptance-testing/).
Pour rétablir la vérité, je me dois de dire que je n’ai pas vraiment participé au bouquin de Gojko. J’ai juste contribué une photo (d’une présentation de Gilles) et j’ai été relecteur du livre.
Mais il est bien quand même.