Prenons l’US INVEST classique “S’authentifier de manière simple” destiné à un client ou un prospect déjà identifié.
Cela signifie que, dans le sprint prévu, le choix qui a été fait est de pouvoir s’authentifier par identifiant et mot de passe, avec 3 tentatives maximum, mais que l’utilisateur ne peut pas encore se rattraper par “mot de passe oublié”. Cela fera l’objet d’une US ultérieure.
L’exemple d’une authentification simple
Voici, au format excel ou avec tout outil de rédaction de plan de test (un lien avec l’outil de ticketing est alors prévu), la tâche correspondante telle que je la prévois dans un premier temps :
Le critère N°2 (voir colonne associée) s’énonce textuellement, la plupart du temps, de la manière suivante :
“Etant donné que je suis client ou prospect identifié,
Quand je tente et échoue 3 fois à saisir mon identifiant
Alors le message d’erreur E2 est affiché ET l’US a été totalement parcourue (sortie de l’US)”
Remarque :
Il est rare de voir le détail du genre :
“Etant donné que je suis client ou prospect identifié,
Quand je saisis mon identifiant une première fois de manière incorrecte
ET je saisis mon identifiant une 2ème fois de manière incorrecte
ET je saisis mon identifiant une 3ème fois
Alors le message d’erreur E2 est affiché ET ’US a été totalement parcourue (sortie de l’US)”
Et puis les observations suite aux 2 premiers essais sont passées sous silence …
Donc Gherkin est très pauvre pour comprendre la tâche (l’US INVEST).
De plus, il n’impose aucune contrainte pour être précis entre 2 mots clés …
Rappel : vous devez, en agile, taguer dans une colonne (par exemple placée à droite), chaque ligne par le ticket qui l’énonce (US initiale ou correction de spécification de l’US).
Ce qu’il faut bien comprendre
On voit bien, à travers l’exemple fourni, que :
- Les critères d’acceptation traversent les RG depuis l’entrée de l’US à une sortie,
- Ils sont donc plus ou moins nombreux. Ils ne forment pas, contrairement à ce que la théorie agile pourrait laisser croire, un ensemble déterminé, dont le “fini” est clair.
- La simplicité d’une US ne change rien. Nous allons démontrer que la réalité est formelle. On ne peut transiger sur le fait que :
a. Les scénarios de test (assimilés aux critères d’acceptation) sont fonction d’une appréciation des 3 amigos.
- La qualité exige en effet une couverture “suffisante” des spécifications
- L’agilité peut cependant admettre que les scénarios de test soient en proportion du risque encouru
b. Ce ne sont pas les critères d’acceptation qui forment la spécification mais les règles de gestion ! Si je mets 4 critères d’acceptation mais que je peux en trouver 8, je vais coder la moitié de mon US.
Précautions à prendre
Ai-je décrit un comportement ou une spécification à travers les critères d’acceptation ?
La réponse est évidemment … un comportement. Le développeur doit donc regarder les RG (chaque ligne QUAND … ALORS) pour comprendre exactement ce qui doit se passer (par exemple, au 1er et 2ème échec). Ce ne sont pas les critères d’acceptation Gherkin qui expliquent ce qu’il doit développer, mais le détail de chaque action du scénario de test.
L’autre point important est de se dire : “Ai-je écrit suffisamment de critères pour décrire et tester totalement mon US ?” ou encore “Comment vais-je concevoir mes critères d’acceptation pour considérer que j’ai suffisamment testé mon US ?”.
Je peux en effet trouver d’autres critères qui amèneront à réussir à s’authentifier mais pas au 1er essai. On peut ainsi buter jusqu’à 2 fois sur l’identifiant et 2 fois sur le mot de passe, et entrer sur le site !
Pourquoi ai-je décidé d’éliminer tous ces autres critères ? Ai-je eu raison ? Peut-on envisager une démarche algorithmique pour décider ? Toutes ces questions trouvent leur réponse dans la suite de cette série d’articles.
En conclusion, une erreur courante et fatale en agile : l’absence de documentation des règles métiers
On retiendra que les critères d’acceptation d’US mis en évidence en agile ne peuvent être conçus que s’il y a explicitement des règles de gestion qui spécifient les exigences fonctionnelles de la solution.
Il faut en agile définir les critères d’acceptation, mais la majorité des projets, et les agilistes qui les inspirent, oublient une rubrique de documentation indispensable et source de ces critères (donc indispensable si on y réfléchit) : les exigences fonctionnelles appelées règles de gestion (et pouvant se référer à des règles métiers).
Ne mettre en documentation que les critères d’acceptation, même s’ils sont la source de la programmation et tests du développeur en TDD, exposent à de nombreuses désillusions et erreurs :
- Des spécifications incomplètes
- Des développements incomplets
- Des développements incompris
- Des fautes d’interprétation, Gherkin étant beaucoup trop permissif : les mots clés et les “ET” ne suffisent pas pour être précis … La forme, qui oblige le respect du “gabarit Gherkin”, prime trop souvent sur le fond.
Certes le développeur attend un critère d’acceptation pour développer, je l’entends, mais le vrai dialogue doit porter sur le contenu des exigences fonctionnelles, pour s’assurer de leur justesse (elles doivent être pertinentes et non ambiguës), les comprendre, vérifier leur complétude … D’autant que nous allons voir que les critères d’acceptation sont, eux, générés par un algorithme laissant comme simple marge de manoeuvre de fixer son critère d’arrêt.
Trois messages clairs émergent en conclusion de cet article et pour la suite :
- Réintroduisons le terme d’exigences dans les spécifications agiles, en les documentant de manière légère mais plus précise.
- Inversement, générons les critères d’acceptation (disons les « scénarios de test », un changement de terminologie qui a fait bien dégâts par incompréhension …) de manière efficace et rapide !
- Allons au-delà des US privilégiées par les démarches de type Scrum, et montrons comment, en agile, tester aussi les fonctionnalités (ayant du sens pour les métiers, nécessaires pour valider un produit dans son ensemble) en étendant les concepts.
L’auteur
Didier JOLIOT, Ingénieur Coach agile et formateur
Didier a une grande expérience professionnelle : développeur puis responsable qualité et certification de logiciels temps réels critiques. Ex : Airbus (A320, A340), missiles, spatial, nucléaire, sous-marins, … Il a été ensuite expert spécifications et tests auprès d’équipes MOE, puis de MOA bancaires. Il a été aussi directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il pratique depuis 2012 l’agilité. Il a été coach agile pour le Product management de très gros projets « agiles à l’échelle » au Crédit Agricole et à la Société Générale, et pour de nombreuses équipes Scrum.
Il a écrit 5 livres et de nombreux articles. Il enseigne, depuis des années, dans plusieurs écoles d’ingénieur et dans les entreprises. Il a créé, de plus, plusieurs méthodes : le langage « Business Modeling Language (BML) », l’algorithme ATDD des tamis successifs, la CNV-A, etc.
