Vous devez définir les « données » pour être précis dans votre spécification. Que dire de cette possibilité dans un outil d’ATDD ?
Quelles données peut-on gérer ?
Dans un tel outil vous devez pouvoir les structurer à votre convenance.
Pour illustrer ce sujet, vous noterez dans la capture d’écran ci-dessous, que j’ai créé des Objets Métiers (entités) et des attributs (données).
On peut évidemment définir des valeurs, ou des propriétés, à ces données.
L’outil permet de tracer ensuite leur utilisation dans les spécifications de test (tables de décision associées aux fonctionnalités). On pourra mettre dans une table « l’OM client est créé » ou bien « le statut du client devient «’créé’ », suivant la hauteur de point de vue que l’on souhaite.
De la notion de donnée à la notion de “sujet”
J’ai aussi, par exemple, mis des messages d’erreur, messages d’aide, des images, ou des maquettes afin d’identifier leur utilisation dans des tables de décision … Tout est à la main de l’utilisateur pourvu qu’il puisse poser des assertions sur des “sujets” (en condition ou en observation).
Le terme “sujet” étend la notion de donnée. L’utilisateur pourra dire ainsi « la maquette X est affichée « . Il pourra avoir la liste des maquettes utilisées dans l’application, et où …
Vérifiez que cette possibilité de poser tout type d’assertion sur tout type de sujet est prise en compte dans un tel outil.
Gestion des tests
Trois points notables :
- Un outil ATDD doit laisser le soin à l’utilisateur d’organiser les plans de test. Personnellement j’ai utilisé la possibilité de gérer les plans par niveaux et par acteur (notamment le PO et le Business Analyst). Là encore, un outil rend le service, mais les actions pour l’utilisateur doivent être simples (nommage facile des scénarii, classements automatisés et non pas manuels …)
- La préparation des valeurs des données de test doit être aussi simple d’utilisation. Si l’outil propose des possibilités de « jeux de données » et des « combinaison de jeux de données », alors la documentation sur ce sujet, pour comprendre la portée de ces 2 concepts, doit être compréhensible, avec des exemples.
- Le générateur ATDD doit, non seulement optimiser le nombre de scénarios de test, mais aussi optimiser le nombre de tests vs le nombre de scénarios, en combinant intelligemment les données.
Reste à vous expliquer le générateur de test dans un outil ATDD : ce sera l’objet du prochain article …
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 » …
