Terminons notre conclusion sur l’ATDD manuelle et l’ATDD automatisée :
- Leurs convergences et leurs divergences
- Les remarques sur l’ATDD manuelle qui enrichiront l’ATDD automatisée
Structuration de la documentation et outillage
Normalement une US INVEST donne lieu à une fonctionnalité dans le produit, c’est-à-dire “une tâche métier”. Les “corrections de spécification” devraient être traitées comme pour les bugs. Ce sont des tickets à évaluer, attachés au plus bas, c’est-à-dire une tâche existante.
Si vous les considérez comme des US (ce que nous avons dénoncé dans un article précédent, elles ne sont plus INVEST), plusieurs US de nature différente (les INVEST et les corrections) pointent sur la même tâche et sa documentation.
Concernant les tickets de “haut niveau”, ce sont donc des histoires de granularité plus ou moins importantes. Une fois réalisées, elles sont fermées. Il faut, en principe, en recréer pour retoucher la fonctionnalité associée !
Pour l’ATDD automatisée, l’outil de référentiel des exigences est spécialisé (ex: YEST) et permet :
- Les liens avec un outil de ticketing comme Jira
- La génération automatique des tests (mais sans tamis possibles)
- La traduction automatique des tests en scripts pour l’automate de test (ex: Cucumber)
- L’export des tests vers un outil de pilotage des tests (Xray, Squash, …)
Critères d’acceptation : le débat
La notion de critère d’acceptation est née avec l’agile et le TDD. Le développeur codera et testera de manière incrémentale et itérative chaque US, en partie à partir des critères d’acceptation.
Dans l’idée de ses auteurs, chaque critère doit être discuté par les 3 amigos (Product Owner, développeur, testeur). Il n’était pas question qu’un outil les génère. Les critères d’acceptation étaient le résultat d’échanges et de débats entre les 3 amigos. Mais de l’eau a coulé sous les ponts … et les processus inhérents aux pratiques informatiques progressent.
Si un générateur vous les livre en un bloc, que reste-t-il à discuter ?
C’est la raison pour laquelle j’ai posé, avec les outils actuels, que la discussion était sur les exigences fonctionnelles de type “règles de gestion”. J’ai montré qu’un texte de type Gherkin pouvait être utilisé pour ces RG … quoique le “Etant donné que” s’avérait peu utile (a contrario la notion d’étape dans une US est importante).
Dans l’hypothèse d’un algorithme qui induit une génération de scénarios de test liée aux risques, alors :
- Les exigences fonctionnelles retrouvent leur formulation traditionnelle : Quand … Alors
- Les exigences sont les points de discussion entre les 3 amigos, même si pour chaque scénario de test, on peut expliquer les règles sur lesquelles on passe (en négligeant les autres).
- Les critères d’acceptation sont les scénarios de test (sans les résultats intermédiaires) traversant l’élément de bout en bout (du point d’entrée à un point de sortie) utiles pour le développeur et sa démarche TDD.
- Avec un algorithme, je peux, en effet, appeler critère d’acceptation la notion orthogonale aux exigences qui induira une sélection de celles-ci et qui pourra être programmée et testée par le développeur de manière itérative et incrémentale. La forme « Étant donné que … Quand … Alors” est bien utilisée (même si souvent le « Étant donné que” explicite les pré-conditions et qu’on retrouve souvent la/les même(s) libellé(s), comme le montre la forme tabulaire utilisée pour les tâches).
- Les critères d’acceptation peuvent être discutés tous ensemble (et non séparément, ce qui s’avère plus long). On ne polémique pas sur le critère à créer ou non, mais sur le niveau de risque de l’élément. C’est ce paramètre qui détermine en effet la fin de génération des tests !
Les articles ont montré, enfin, que les tests des fonctionnalités (parcours, MUC, UC) peuvent aussi s’automatiser, en prenant des modèles qui prennent de la hauteur, et j’ai expliqué comment faire cela (reprise des objectifs de détail, notion d’alternatives).
Les outils ATDD actuels devraient s’en inspirer et apporter de la cohérence entre les différents niveaux de modélisation, ce qui reste à faire …
De fait, l’avenir serait, in fine, d’avoir ce dernier point de vue comme unique. Cela implique notamment d’avoir des outils ATDD futurs avec un générateur non plus “tout ou rien” mais par “tamis successifs”.
A retenir
En attendant cette unification des 2 approches ATDD, vous voyez que si vous êtes dépourvu d’un outil vous avez moyen simplement et de manière très efficace et rapide de produire vos scénarios de test grâce à deux dispositifs présentés dans mes articles :
- Le langage BML (Business Modeling Language) qui spécifie les US, et autres fonctionnalités plus importantes, de manière précise (fondée sur une grammaire, extensible en ajoutant des types de sujet, par exemple, selon ses besoins). Ce langage est compréhensible par tous (dont PO et métiers), permettant les échanges et les débats.
Ce n’est pas un langage graphique pour “programmer” un outil BPM.
- L’algorithme des tamis successifs qui sélectionne les scénarios à réaliser en fonction des risques (ou de la valeur de l’élément à tester).
C’est le sens du sketchnote ci-après qui termine cette série d’articles !
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.
