Voyons comment mettre des spécifications de test agiles dans un outil ATDD, tant au niveau les plus fins qu’au niveau des fonctionnalités les plus élevées.
Évolutions agiles des spécifications de test d’une tâche
Dès lors qu’une UC est modifiée par une demande du PO, il faut :
– Corriger sa modélisation (ajouter/supprimer des tâches et/ou les chemins du graphique)
– Mais aussi modifier dans les tables de décision. En effet une demande PO peut être au niveau très fin des critères d’acceptation qui changent.
Dans ce cas, la colonne « traçabilité agile » indique l’US (ou autre type de ticket éventuel) qui crée le critère d’acceptation dans trois cas :
- Soit créer une nouvelle ligne,
- Soit supprimer une ligne (un ticket pour faire cette suppression !),
- Soit modifier le texte du critère d’acceptation dans une ligne.
Table de décision d’un élément fonctionnel “haut niveau” de l’architecture
Pour faire simple, disons qu’un élément d’un modèle ATDD doit avoir, en plus de sa description graphique, une table de décision, comme pour une tâche.
De fait on va retrouver “des critères d’acceptation” mais, cette fois-ci, pour valider ou non une fonctionnalité du produit bien plus grande qu’un simple UC (symbolisé par une “tâche” en YEST).
La table suit le même modèle que celui déjà indiqué, sauf que :
- Les critères d’acceptation de ce niveau sont des règles de comportement attendues d’éléments complexes (a minima des tâches). Il nous faut donc créer des « règles métiers » qui prennent de la hauteur par rapport aux critères d’acceptation des US (« règles de gestion »), bien trop nombreuses et qui seront déjà testées dans le détail lorsque vous aurez à tester l’élément considéré.
L’outil ne vous dit pas comment faire !
- On peut y mettre une traçabilité agile. Par exemple ce qui exige une évolution d’une macro-fonctionnalité du produit peut être une epic. C’est le ticket de réalisation qui justifie un développement pour la faire évoluer. Autrement dit on retrouvera les artefacts agiles de haut niveau mis en cause pour les modifications souhaitées, tout comme les US à l’intérieur d’une tâche.
Alors quels conseils pour réaliser une documentation agile de ces fonctionnalités de haut niveau ?
Prenons un exemple. Supposons la macro-UC ci-dessous :
Par rapport à la table de décision interne de l’UC “Sélectionner une fiche S1 existante” qui comporte à elle seule 25 lignes, le PO retient, et c’est visible sur le schéma, deux résultats :
- Quand la fonctionnalité UC 11 a été exécutée Alors la recherche est infructueuse (et la table de décision dans sa colonne “direction suivante” indique sortie de la Macro-UC)
- Quand la fonctionnalité UC11 a été exécutée Alors la fiche S1 est dupliquée (et la direction suivante est l’UC10)
J’ai donc créé 2 lignes pour la table de décision de la macro-UC ! Vous pouvez compléter ensuite pour les autres UC, et vous avez donc des critères d’acceptation d’une macro-UC.
La technique utilisée consiste donc à considérer chaque sous-élément (ici UC) comme une boîte noire pour considérer ses résultats attendus (cf. le graphique, voire les alternatives si nécessaire – par exemple je veux considérer les erreurs 1 et 2 de recherche infructueuse qui me paraissent importantes à tester pour voir ensuite à un niveau au-delà de la Macro-UC comment l’utilisateur va continuer son parcours).
La notion de table de décision d’une macro-UC reste donc valable. On y met les entrées et comportements de chaque sous-élément, en correspondance avec les tables de décision de chaque sous-élément.
Cohérence entre critères boîte noire et critères boîte blanche
Quels sont les problèmes posés par les différents niveaux d’abstraction ?
Dans notre exemple ci-dessus, Il ne faudrait pas que l’UC 11 décide de gérer une erreur X qui amène, à sa suite, à l’UC “créer une fiche ex-nihilo”, mais sans que le modèle de macro-UC ne l’intègre. Il faut donc une cohérence entre critères d’acceptation d’un sous-élément (critères boîte blanche) et les critères de son comportement dans l’élément supérieur (critères boîte noire).
Ce paragraphe met en évidence que le principe de la table de décision est limpide, mais que son remplissage exige une compétence PO forte.
Et quelle aide apporte les outils sur ce sujet ?
Les outils ne prévoient pas, malheureusement, cette possibilité de faire des critères d’acceptation « boîte noire » en relation avec les critères d’acceptation boîte blanche. Autrement dit, les outils n’aident pas à maintenir la cohérence entre vue générale (critère d’acceptation boîte noire des sous-éléments) et vue détaillée (critères d’acceptation boîte blanche). Si vous créez un nouveau four “numérique”, vous pouvez très bien décrire qu’un plat sort du four après cuisson et constater, après une trop longue cuisson, qu’il est brûlé, alors que vous n’avez jamais spécifié ce cas dans la spécification de test de l’US “gestion du four” !
Vous faîtes vos tables de « haut niveau » de manière indépendante et peut-être de manière incohérente, par rapport aux tables des tâches. Dommage !
En conclusion
Les spécifications ATDD sont des représentations visuelles et tabulaires du système pour un cas d’usage du produit (influence de l’agile).
Celui-ci est décrit du point de vue métier ; c’est son architecture en termes d’éléments métiers à un instant T.
- Les éléments apparaissent visuellement par des modèles impliquant leurs éléments « fils », avec les chemins de dépendances fonctionnelles (on peut aller de l’élément A vers l’élément B).
- Pour valider chaque élément de cette architecture il faut des critères d’acceptation.
- Pour une tâche, chaque critère est rattaché avec les tickets de réalisation en cause. Autrement dit, une US donne lieu à une création d’une tâche (qui sera alors INVEST). La tâche évoluera par des tickets de bug de spécification (ou d’autres US non INVEST -« de détail », au choix de l’équipe).
- Un critère d’acceptation est représenté par une ligne de la table de décision.
- Les critères d’acceptation pour un élément métier, autre qu’une tâche, est un comportement « boîte noire » de cet élément.
L’ATDD est donc un complément au BDD.
Faire d’une US de détail (ajout/modification d’un critère d’acceptation) une modélisation en fonctionnalité est donc une erreur. Inversement une US qui exigerait de l’ATDD c’est le signe d’une US trop complexe !
En définitive, nous recommandons qu’une tâche ATDD soit au départ une US INVEST.
Ensuite, pour chacune, on peut suivre ses micro-évolutions comme des US tracées dans sa table de décision, ou bien on peut créer des « bugs de spécification » (le type de ticket est au choix de l’équipe).
En généralisant, les éléments de haut niveau sont des fonctionnalités plus ou moins grosses prévues pour le produit. On peut tracer chacune de leurs critères d’acceptation (à inventer par boîte noire par le concepteur) par rapport aux histoires qui permettent de les réaliser au fur et à mesure dans les sprints.
Les tables de décision des éléments qui ne sont pas des tâches, sont élaborées sans contrôle des outils ATDD.
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 », …
Une réponse
Salutations, et après avoir vraiment regardé le contenu que vous fournissez, je prouve que vous êtes créatif dans le sens le plus large du terme dans le domaine des tests de logiciels et autres et ses dépendances, et en conséquence, je vous salue pour cette réalisation et cette créativité.