L’ATDD comporte un aspect graphique qui permet d’identifier les éléments d’un système développé en agile et leurs dépendances fonctionnelles (mais sans en donner les règles).
Les tâches, nous l’avons dit dans un précédent article, sont initialement des US INVEST.
Bien, mais trois questions sont soulevées :
- Comment, décrire, comme en BDD, les critères d’acceptation des « tâches » (c’est-à-dire celle de l’US, éventuellement corrigée dans ses détails par des tickets de correction) ?
- Comment les tâches et les US sont-elles réellement liées ? Quels sont les liens entre UC et fonctionnalités agiles (features/epics que les agilistes utilisent) ?
- Comment les règles d’enchaînement qui expliquent les dépendances graphiques s’expriment-elles pour les éléments composés d’autres éléments ?
Description d’une table de décision ATDD pour une tâche
C’est une forme de spécification qui va au-delà de Gherkin.
Notons que cette forme de spécification de test est connue depuis longtemps. Je vous renvoie, par exemple, au livre « Performances des SI » – Didier JOLIOT- Hermès Lavoisier – 2003.
Elle indique :
- Les critères d’acceptation de la tâche sous la forme de colonnes au lieu d’un texte : conditions et résultat essentiellement,
- Mais aussi précise le comportement attendu ensuite : Comment le système doit réagir après avoir exécuté le critère ? Contrôler le prochain critère ? Sortir de la tâche et pour aller où ?
- Des commentaires sous forme de colonnes. On peut ainsi, par exemple, mettre du texte « libre » pour chaque ligne correspondante à un critère d’acceptation : une description de l’exigence, ou un objectif associé, etc.
Et enfin, on met l’US correspondante à chaque critère. Au début la tâche peut être une US donc INVEST (critères définis pour une US par B. Wake puis M. Cohn).
Remarque :
On notera qu’il y a possibilité d’utiliser une colonne par condition et une seule colonne pour les observations, en utilisant, tout compte fait, une approche textuelle de type BDD. D’autres outils ne travaillent que sur des colonnes d’assertions (en condition ou en observation) ce qui rend la lisibilité meilleure. Ils montrent ainsi qu’une assertion de condition (Quand X>0) peut réutiliser une assertion d’observation préalable (Alors X>0).
Les tables de décision ATDD sont une forme de spécification supérieure au BDD
Le BDD est, sous sa forme textuelle Gherkin, une représentation essentielle pour les conditions (Quand) et les observations (Alors). Dans l’ATDD vous constaterez que vous retrouvez ce résultat, mais sous forme tabulaire (colonnes de condition, et une colonne résultat dans YEST). Autrement dit, vu sous cet angle, on peut dire que l’ATDD est une variante tabulaire du BDD.
Mais c’est aussi bien plus. Avec les colonnes supplémentaires, vous spécifiez la sortie de l’élément, ce qui est indispensable pour tester un élément au sein d’autres éléments ! Et puis, alors que le BDD se focalise sur un critère d’acceptation, l’approche ATDD permet de réfléchir à la régression.
Nous pourrions ajouter que l’ATDD en général permet des algorithmes de génération automatique de test, alors que le BDD ne propose pas ce type d’approche. Nous le verrons ultérieurement en parlant de l’algorithme des tamis successifs qui est indépendant de tout outil.
Complétude d’une table de décision
Une table de décision consistante est une spécification qui montre la complétude de la table (ensemble des conditions en entrée), à supposer que toutes les conditions aient été posées. Je peux très bien poser 3 conditions pour une donnée A et en oublier une 4eme, 3 conditions pour une donnée B, et donc avoir 9 combinaisons au lieu de 12. Je serais consistant, mais non complet. Souvent on parle de “complétude”, tout en oubliant qu’en fait on travaille sur un aspect relatif, la consistance, et non pas absolu.
Un outil ATDD peut/doit nous aider fortement à vérifier la consistance d’une table. Ce n’est pas toujours aussi explicite que nous le souhaiterions en termes d’ergonomie, mais vous avez plusieurs moyens pour la vérifier ou y parvenir.
A propos de l’auteur
Didier JOLIOT est formateur de l’offre Modern Product Agility (MPA) mise en place avec Stéphane BADREAU et couvrant tant l’aspect de savoir-faire agile que celui du savoir-être.
Le blog MPA : https://mpa.systeme.io
Didier a une grande expérience professionnelle (plus de 40 ans) et très diversifiée (cf. LinkedIn).
Il a d’abord été développeur puis responsable qualité et certification de logiciels temps réels critiques (Airbus, systèmes d’armes, nucléaire …). Il a été ensuite consultant pour les MOE bancaires, puis AMOA, directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il a pratiqué le cycle en V, et, depuis 2012, l’agilité. Il a notamment conduit les spécifications et les tests fonctionnels de très gros projets de SI (Crédit Agricole, Société Générale).
En devenant alors coach agile il a aidé de nombreuses équipes Scrum et de nombreux programmes « à l’échelle » sur des bases SAFe.
Il a écrit 5 ouvrages et de nombreux articles. Il a créé, de plus, plusieurs méthodes dans des domaines variés, notamment le langage de spécification de test « Business Modeling Language (BML) », les tests ATDD avec « l’algorithme des tamis successifs » …
