Prenons l’exemple de la fonctionnalité F représentée par le schéma ci-dessous :
Voyons comment traduire ce graphique dans une table ATDD qui nous fournira systématiquement les scénarios de test et, accessoirement, montrera comment les exigences fonctionnelles pourraient s’énoncer en Gherkin comme des RG de haut niveau.
Réaliser une table ATDD à partir du langage graphique BML
Utilisons la liste des “transitions en entrée/sortie (E/S)”. A droite des 3 colonnes (transition d’entrée – boîte et transition de sortie, mettons, dans des colonnes supplémentaires, les scénarios de test qui “traversent” la fonctionnalité F avec l’algorithme des tamis successifs (pour l’exemple on ne représentera que les 3ers scénarios).
Chaque ligne peut se traduire, dans une modélisation de haut niveau qui est la traduction textuelle du schéma, en une exigence fonctionnelle (d’ailleurs l’outil ARD, par exemple, permet d’automatiser cette transformation) :
Quand l’utilisateur/le système entre par la transition <Texte de Te>
ET exécute la boîte B >Texte du traitement ou de la décision>
Alors l’utilisateur/le système peut arriver à
la situation (ou au résultat) porté par la transition <Texte de Ts>
Voyons donc comment grâce à cette solution nous pouvons atteindre la couverture de test souhaitée, jusqu’aux dernières étapes de l’algorithme s’il faut.
Deux types de table sont étudiés qui dépendent des choix de modélisation utilisés.
Table d’une fonctionnalité avec une modélisation détaillée
Vous voyez que la construction des scénarios de test est simple en suivant l’algorithme, et qu’on peut visuellement voir les affirmations non encore testées et les combinaisons absentes.
On peut noter (voir scénario S4) qu’il peut y avoir des navigations dans la table obligeant à numéroter les pas de test.
Table d’une fonctionnalité avec une modélisation compacte
La modélisation réalisée donne le schéma suivant :
La table des transitions en E/S donne moins de lignes et chaque cellule :
- Doit numéroter le pas de test (ou les pas de test si on revient plusieurs fois sur cette ligne)
- Peut être cochée avec un commentaire, s’il faut, ou sinon l’alternative/la combinaison d’alternatives utilisée
Cette table représente des exigences fonctionnelles de haut niveau et des scénarios de test (critères d’acceptation commentés par les résultats intermédiaires) déduits par l’algorithme des tamis successifs.
Dans notre exemple, la table se présente de la manière suivante (on s’arrêtera pour l’exemple à trois scénarios) :
La lecture, d’une part par un testeur des scénarios, et d’autre part celle d’un développeur, est simple. Cela signifie que c’est sur la liste des exigences que doit se porter l’attention des 3 amigos, même si le TDD en agile permet le développement par “critère d’acceptation” (scénario de test non commenté).
On retiendra que la forme de modélisation change la table des transitions en E/S, mais que l’algorithme reste facile à appliquer.
Comment s’effectue, pour une fonctionnalité de haut niveau, et en ATDD manuel, le passage d’un scénario de test à ses tests ?
En ATDD manuel, le PO a besoin d’orientation sur le scénario à exécuter (à partir du moment où j’ai un événement déclencheur avec telle(s) condition(s), que j’effectue le traitement X, alors j’obtiens le résultat de type “Alternative Y”).
Il ne suit pas un pas à pas de plusieurs pages ! C’est tout simplement impossible et ce serait trop coûteux en termes de documentation.
Donc le graphique succinct suffit et on lui ajoute, s’il veut plus de détails
- Soit un test correspondant au passage souhaité dans l’élément X (jusqu’à, s’il faut, aller consulter le test adéquat, avec toutes les données utiles, pour exécuter une tâche métier).
- Soit une colonne commentaire pour lui indiquer les saisies majeures à réaliser, c’est-à-dire celles qui auront un impact pour la suite du test.
La documentation doit être adéquate par rapport à la hauteur de point de vue qu’aura le testeur, comme nous l’avions déjà souligné.
L’auteur
Didier JOLIOT, Ingénieur Coach agile et formateur
Didier a une grande expérience professionnelle : développeur puis responsable qualité et certification de logiciels temps réels critiques. Ex : Airbus (A320, A340), missiles, spatial, nucléaire, sous-marins, … Il a été ensuite expert spécifications et tests auprès d’équipes MOE, puis de MOA bancaires. Il a été aussi directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il pratique depuis 2012 l’agilité. Il a été coach agile pour le Product management de très gros projets « agiles à l’échelle » au Crédit Agricole et à la Société Générale, et pour de nombreuses équipes Scrum.
Il a écrit 5 livres et de nombreux articles. Il enseigne, depuis des années, dans plusieurs écoles d’ingénieur et dans les entreprises. Il a créé, de plus, plusieurs méthodes : le langage « Business Modeling Language (BML) », l’algorithme ATDD des tamis successifs, la CNV-A, etc.
