Nous voici arrivés en fin de l’étude ATDD pour comprendre ce dont il s’agit et pour montrer son utilisation en agile à l’aide d’un outil.
Un étonnement : pourquoi l’ATDD n’est-il pas encore vu comme un outil indispensable à l’agile ?
Il est assez incroyable de voir qu’en 2022 l’ATDD est encore au stade embryonnaire alors que, biberonné aux spécifications semi-formelles et aux générateurs automatiques de tests dans le cadre de développement de logiciels embarqués, il me paraît évident que l’agilité passe par :
- Une spécification non ambigüe et structurée
- Des plans de test générés automatiquement à partir des spécifications. Cela ferait gagner en qualité et en délai nos développements ! Bref, l’ATDD est la voie tracée vers l’agilité.
Les outils ATDD restent marginaux, alors que les techniques graphiques et tables de décision, très simples (pas de MBT fondé sur des spécifications impossibles à manipuler par des PO et des end-users), sont connues depuis très longtemps. Personnellement, j’ai 25 ans d’ATDD avant même que ce terme se popularise… je parlais de démarche (ce qui reste vrai), de méthode “MODEL & TEST” et d’“algorithme des tamis successifs”. Et “l’ATDD” signifiait alors l’utilisation de fonctionnalités graphiques et de feuilles Excel. Mais, à la lecture, vous voyez que tout reste d’actualité !
Les freins aux outils d’ATDD
Les outils ATDD d’aujourd’hui requièrent une formation, comme tout logiciel, mais surtout une rigueur et, encore plus, une connaissance fine de leurs principes. La documentation et le coaching me paraissent fondamentaux.
Ils demandent encore quelques améliorations aussi pour décharger l’utilisateur de trop de manipulations, pour lui faire mieux découvrir des fonctionnalités trop cachées, et pour tenir compte vraiment de l’agile. Les principes sont là, mais les solutions ne sont pas encore toutes optimales ou, tout simplement, décrites. On vise, par exemple, des plans de test par US et des tests de régression identifiés automatiquement ; le générateur devrait donc les sortir sans laisser un travail trop fastidieux à l’utilisateur.
L’ergonomie des outils pour qu’ils soient faciles d’utilisation, la documentation et le support doivent être à la hauteur des enjeux.
Il faut aussi apprendre à utiliser ces outils de manière optimale et sûre. Parfois une erreur de l’opérateur, difficile à repérer, et la génération ne correspond pas du tout à vos attentes … Il y a en effet des subtilités pour les maîtriser, bien au-delà du manuel utilisateur. Par exemple, la gestion des données exige leur identification, leur classement, les conditions associées, les valeurs à leur affecter … Des progrès restent à faire dans ces outils très riches et disruptifs, pour mieux guider l’opérateur, lui faciliter la compréhension des concepts, donc leur utilisation.
Ce ne sont pas des outils “presse-boutons”
Attention : ne croyez pas que l’utilisation de l’outil et sa saisie soient aussi faciles que la présentation semble le dire. Beaucoup de réflexions sont à mener pour configurer, organiser la stratégie de test dans l’outil, choisir les options possibles, etc.
A ce propos, nous espérons vous avoir bien montré “de visu” quelques exemples. Ils ne sont pas exhaustifs et nous avons opté pour certaines solutions (vous pouvez en trouver d’autres …). Toutefois ces solutions vous ne les trouverez pas dans la documentation standard. Il manque très souvent des retours d’expérience qui expliquent comment un outil a été configuré, et, donc, les avantages/inconvénients associés.
Ils ont aussi d’autres fonctionnalités intéressantes, par exemple les liens avec JIRA, la possibilité de coupler l’outil avec des logiciels de scripts de tests automatisés. Nous ne les avons pas testés alors que la chaîne de production des tests est, en fait, plus complète.
En tout cas ne nous trompons pas, ce sont des outils d’avenir
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 », …
