Dans une démarche agile, nous avons vu que le BDD s’impose essentiellement pour spécifier les tests des User Stories (US). Mais comment faire pour les éléments plus complexes qui représentent des fonctionnalités, ou des macro-fonctionnalités ?
Nous allons présenter la démarche ATDD lorsqu’elle est outillée. Nous pourrons ainsi montrer des copies d’écran. Nous avons en effet voulu vous montrer de manière visuelle, par la pratique, ce que les responsables de spécifications et les testeurs auront comme fonctionnalités à disposition pour appliquer cette démarche. Nous avons ainsi des illustrations concrètes qui seront, nous en sommes sûrs, appréciées.
Ceci a été rendu possible par l’utilisation de l’outil YEST. Même si d’autres outils existent et peuvent avoir d’autres particularités, ce progiciel est représentatif de ce type d’outil apte à répondre aux besoins “grand public” du monde IT. Nous ne parlerons pas d’outils ATDD plus pointus, avec des formalismes compliqués, parfois même non visuels, réservés à des applications extrêmement critiques.
ATDD : des principes visuels
L’ATDD repose sur un outillage qui permettra de gérer des fonctionnalités souhaités par les métiers (ce qu’est le produit à un instant t) et les artefacts agiles (comment le développer); Ce ne sera pas seulement du « dessin », mais le PO, ou le Business Analyst qui l’assiste, pourra poser de la documentation structurée sur les éléments.
L’approche aboutira, in fine (après des ateliers, sur la base, par exemple, des résultats de design thinking), à la « modélisation » du parcours client qui part d’une vision haute, l’enchaînement de macro-fonctionnalités, jusqu’aux détails les plus fins d’un parcours que l’on va appeler « tâches » (ce que certains appellent encore « opérations métiers »).
Chaque macro-fonctionnalité et fonctionnalité d’un parcours sera décomposée en ATDD, par le dessin, en éléments plus fins, jusqu’aux « tâches ». Celles-ci ne se décomposant pas, elles n’ont pas besoin de cet aspect visuel. Le BDD leur suffirait.
Une tâche est-elle une US ? Quel lien ? nous allons y revenir.
Le modèle ci-dessus présente le parcours client pour le cas d’usage A (par exemple pour les produits de catégorie A). Les éléments sous-jacents sont des activités du parcours.
L’objectif d’un parcours client, avec son cas d’usage, peut être vu parfois comme une “macro-initiative” présente dans le Portfolio Management du SI (cours Agilité à l’échelle « MPA » et livre « Gestion de projet agile – S. BADREAU – collection ENI – décembre 2021). C’est, de toute manière, un dossier de modélisation dans les outils ATDD.
Vous noterez sur le schéma que la syntaxe (traduite en palette de “symboles”) est réduite à l’essentiel : point d’entrée, point de sortie, éléments (sous-parcours ou tâche terminale), losange de décision, commentaires.
Elle est en général suffisante … enfin presque ! Pourquoi ?
La notion d’alternative
Il manque dans la palette précédente, et dans beaucoup d’outils ATDD, une notion : l’alternative.
Sur une transition (toute flèche du schéma) je peux vouloir mettre plusieurs conditions métiers à respecter. Par exemple : La sortie de « choisir des produits pour A » (cf. schéma ci-dessus) pour aller vers « figer la commande » nécessite, pour les métiers, de distinguer trois cas différents : panier < 1000 euros, OU panier entre 1000 et 5000 euros, OU panier > 5000 euros. Ces alternatives amènent effectivement des comportements totalement différents du point de vue de l’utilisateur :
- Pour confirmer le comportement de la fonctionnalité à un niveau plus macroscopique (en fait dans la fonctionnalité le panier peut avoir une quinzaine de fourchettes pour son montant)
- Ou pour envisager des tests dans des fonctionnalités en aval.
Ces « alternatives » vous ne pouvez pas toujours les faire apparaître (hormis un commentaire, solution inacceptable). Dans ce cas, un contournement acceptable (comme avec l’outil CA ARD – Computer Associate « Agile Requirement Designer ») est de mettre autant de transitions que de cas allant d’une « boîte » A vers une “boîte” B. Par “boîte il faut entendre les symboles de la palette, hormis les commentaires, par exemple d’un traitement vers une décision pour montrer les différents résultats possibles). Le nombre d’alternatives est rarement plus de 3. Toutefois cette solution n’est pas toujours possible avec l’éditeur graphique ATDD proposé.
ATDD : Prolongement et simplification du MBT
Nous allons voir que l’intérêt de l’ATDD est de concevoir les tests à partir de la démarche de spécification de test, ce qui est surtout intéressant pour les tests “système” et pour la non-régression.
Auparavant, on parlait de MBT (Model Based Testing). En simplifiant les notations de la palette graphique, qui était beaucoup trop riche, ce terme semble disparaître.
L’ATDD vise à permettre le dialogue entre toutes les parties prenantes sur l’architecture fonctionnelle du système et leurs critères d’acceptation, et à générer automatiquement les tests. L’ATDD devient donc appréciée par sa simplicité et par la possibilité de souder l’équipe agile (PO et IT). Son sigle désormais s’impose et devient, à mon sens, synonyme de génération automatique de tests, c’est-à-dire l’identification automatique des tests en amont de l’automatisation des tests (les scripts d’exécution des tests qui restent à “coder”).
Vision hiérarchique du parcours client
On peut, par exemple, à l’intérieur d’une activité d’une macro-initiative, définir des « initiatives agiles », au sens de l’artefact couramment utilisé dans le Portfolio Management en agilité à l’échelle.
Une initiative répond à un objectif tactique de la roadmap (avant de parler plus prosaïquement de fonctionnalités pour l‘utilisateur). C’est une demande de développement de haut niveau.
Par exemple, au sein de l’activité « paramétrer le catalogue pour le cas d’usage A », avoir des initiatives ; c’est ce que montre le schéma ci-après.
L’analyse descendante se poursuit. Nous pouvons détailler l’initiative « Gérer les types de produit et produit du cas d’usage A » en macro-fonctionnalités (nous les avons préfixées par « MUC » : Macro Use Cases).
Remarque :
Les notions de macro-initiative se traduisent dans un outil de ticketing (ex: JIRA) comme l’ouverture d’un projet, et la notion d’initiative peut être un type de ticket à part entière (les initiatives sont les artefacts de plus haut niveau pour réaliser un produit).
Cependant, pour les projets simples, les initiatives (normalement bien visibles dans la roadmap du produit), peuvent ne pas être forcément nécessaires et on peut vouloir faire apparaître directement des macro-fonctionnalités.
Enfin le PO, avec l’aide des utilisateurs, utilise le design thinking pour identifier les fonctionnalités attendues de chaque macro-fonctionnalité.
Vous pouvez constater que nous avons noté « UC » les fonctionnalités exigées. Ce n’est pas anodin. On retrouve des Use Case traditionnels (donc en abrégé « UC ») mais dans le contexte « agile » d’un parcours client (déjà plus sélectif qu’un processus, celui-ci étant beaucoup plus large puisque pouvant intégrer plusieurs cas d’usage).
De plus, un UC n’est pas forcément une « histoire » (epic au sens Scrum). Avec le temps, en effet, le concepteur conservera la fonctionnalité (UC) mais fera peut-être appel à plusieurs tickets de haut niveau (epics en Scrum) pour l’améliorer progressivement dans le temps. Un nouveau ticket s’impose en effet dès que le ticket précédent a été jugé « terminé ». On retrouve donc, de manière opérationnelle, le schéma précédemment fourni :
- D’une part une architecture qui explique les différents tickets de réalisation du système (leur liste, leurs liens éventuels) qui sont les éléments documentaires pour la réalisation durant un sprint.
- Et, d’autre part, une architecture du produit à un instant T qui explique comment il fonctionne tout compte fait, après tous les sprints déjà réalisés. Un élément du produit (un UC par exemple) peut donc être affecté par plusieurs tickets qui le fabrique.
En mode traditionnel nous avions une seule architecture (celle du produit). En agile, nous avons le système qui évolue constamment par des histoires qui amènent à faire évoluer les UC du parcours client (et par-delà l’usage des macro-fonctionnalités).Comme les tickets agiles sont éphémères (mais nécessaires pour les développeurs), la documentation du produit reste celle qui capitalise la connaissance fonctionnelle.
