Evidemment le gros avantage d’un outil ATDD est de produire les scénarios de tests, puis les tests, à partir de la modélisation effectuée : les graphiques et les tables. Que faut-il en penser ?
Points d’attentions à avoir sur un générateur automatique de tests ATDD
Trois points sont au moins à vérifier :
- Un générateur “tout ou rien” ou un générateur par “tamis successifs” ?
L’outil vous propose des tests sur un périmètre, mais avez-vous moyen d’avoir une proposition et une orientation de stratégie pour un nombre de tests plus limité ? La solution d’un générateur livrant tous les tests possibles (“générateur total” n’est pas la solution s’il s’agit pour vous de décocher ensuite manuellement les tests inutiles pour vous, sans être guidé !
Donc si vous avez 25 tests générés mais que vous n’avez que 5 tests à faire (manque de temps, risques faibles …), vous passez du temps à analyser vous-mêmes, ceux que vous gardez ! L’intérêt d’un générateur faiblit grandement …
L’outil doit utiliser une stratégie par types de cibles à atteindre sur le modèle graphique. Certains types sont facilement atteignables (ex: passer une fois par chaque sous-élément) d’autres plus complexes (ex: passer par tous les chemins du point d’entrée aux points de sorties). En ce qui me concerne, j’utilise sur un modèle ATDD une manière précise pour filtrer petit à petit les cibles. C’est, ce que j’ai appelé, “l’algorithme des tamis successifs” : près d’une dizaine de stratégies qui couvrent petit à petit les spécifications de test ATDD (“les cibles”). Cela marche depuis très longtemps et a été utilisé sur tout type de système, depuis des logiciels embarqués jusqu’aux systèmes d’informations bancaires, des plus simples aux plus complexes (plusieurs centaines de M€).
Il faut savoir que les outils ATDD, même en posant des colonnes supplémentaires dans les tables de décision, ne peuvent pas automatiser simplement cet algorithme et donc les outils ATDD n’ont pas toujours un générateur modulable.
- Le générateur tient-il compte de contraintes métiers ?
Avec certains outils vous pouvez poser des contraintes référentielles, mais pas avec tous. Par exemple si X>0 alors il est impossible que Y<0. Dès lors proposer un chemin qui contiendrait la première condition, puis la 2eme, n’a aucun sens métier.
- Le générateur supporte-t-il les boucles ?
La modélisation peut avoir des boucles, quoiqu’on en dise. Or, si vous testez un outil ATDD sur une modélisation avec boucles, encore plus lorsqu’il y a des contraintes sur celles-ci (j’ai pris l’exemple de 2 tentatives maximum pour entrer un mot de passe pour sortir d’une fonctionnalité), alors le générateur peut s’y perdre … Il faut alors connaître son fonctionnement intime pour chercher à l’aider et contourner son problème ! Ce n’est pas acceptable.
Puissance d’un outil ATDD
En forçant l’utilisateur à gérer ses données et les conditions sur elles, vous pouvez avoir des analyses d’impact très puissantes.
Vous pouvez aussi vérifier la complétude de vos tables de décision. Il suffit de scruter les conditions non encore mises en jeu.
Un outil ATDD peut proposer des analyses pour « débugger » les problèmes qui, si elles sont bien maîtrisées, me paraissent puissantes.
Vous devez avoir dans un outil ATDD des analyses de couverture très fines. Or cette fonctionnalité, si elle existe pour un générateur “total”, c’est pour découvrir que le générateur n’a pas réussi à résoudre certains chemins !
Cependant une autre idée est de vérifier que l’outil est aussi capable de vous donner des taux de couverture correspondant aux différents tamis, s’il est modulable. Ainsi vous pouvez mieux jauger votre effort de test ou votre critère d’arrêt des tests.
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 », …
