Les tableaux présentés jusqu’à présent montrent que chaque affirmation BML peut faire l’objet d’une cellule dans un tableau. On se retrouve sous la forme de l’ATDD “automatisée” (avec un générateur automatique des scénarios de test).
- Il suffit en effet de placer une colonne par sujet et la cellule contenant l’affirmation simple ou avec un OU d’affirmations simples.
- Les RG doivent être consistantes sur chaque étape de l’US (représenter tous les cas liés à l’étape)
Exemple :
| Quand | X | Y | Alors | Z | direction(par défaut étape suivante) |
| Etape E1 – RG1 | X=0 OU X compris entre 10 et 20 (bornes comprises) | Y >0 quelconque | Z non modifié | ||
| RG2 | X est dans l’intervalle (1,9) | Y=0 | Z = 2*Y | ||
| Etape E2 etc. |
Forme textuelle ou tabulaire de BML
L’avantage de la forme tabulaire ATDD, outre le fait que la lisibilité est améliorée, est de voir la consistance de la spécification. Toutes les lignes d’une étape présentent-elles bien tous les cas possibles (au regard des conditions fournies) ?
Ex : que se passe-t-il si X (entier entre 0 et 20 compris) se situe dans l’intervalle (1,9) et Y différent de 0 ?
BML et l’importance des analyses d’impact sur tout le système
Nous voyons que, si nous utilisons BML dans un référentiel d’exigences, alors (à condition que l’outil soit bien utilisé et bien configuré pour balayer toutes les tâches du système) nous pouvons faire des analyses d’impact : nous pouvons juger des conséquences d’une nouvelle règle de gestion sur le système ou des conséquences d’une modification de cette dernière.
Supposons que j’ajoute une ligne dans une table (ex : RG2), quelles sont les utilisations des données créées/modifiées/supprimées dans une autre table (une autre tâche, éventuellement d’une autre epic) ?
Ex : j’ai une évaluation de risque qui me donne un “risque client” soit vert, soit rouge. Je change cette règle pour y mettre vert, orange ou rouge. Cela marchera bien pour le ticket de correction de spécification (qui s’intègre dans la tâche « Évaluer le risque client” du référentiel d’exigences) … mais si ce risque permettait de “Donner un crédit” il faut impérativement prévoir de la corriger pour intégrer le nouveau risque client orange ! Et que dire des tâches que l’on ne soupçonne pas être impactées …
La rigueur apportée par BML sur les données, plutôt qu’un texte informel coincé entre des mots clés, permet cette analyse qui est souvent, malheureusement, mal conduite en agile (quand elle l’est !).
De fait, on comprend, en ayant une approche claire et haute du produit, que les tests d’US ont leurs limites. Il faut impérativement des tests métiers parcourant plusieurs tâches, et même traversant plusieurs epics dans le parcours client.
Le produit, même réalisé en agile, est un système, qui, ne l’oublions pas, doit être validé dans son ensemble. Il se peut qu’il contienne plusieurs centaines de tâches ! Le “quadrant des tests en agile” ne se restreint pas aux tests de composants des développeurs et des tests d’US (aussi pertinents soient-ils).
Remarque : Il y a même, en dehors des tests, un dernier niveau d’analyse à entreprendre. La décision que je prends en touchant une règle existante ne va-t-elle pas avoir une conséquence imprévue sur mon activité ?
Autrement dit, on voit que les tests peuvent ne pas détecter d’erreur et pourtant le produit peut :
- Receler des bugs (exemple du cas orange non prévu par ailleurs et provoquant un plantage de “risque client inconnu”).
- Provoquer des fautes (cas orange intégré à un cas rouge, par exemple dans une contrée lointaine du système …).
- Engendrer une insatisfaction utilisateur (cas où l’on n’avait pas prévu, avec nos nouveaux choix de calcul du risque, que notre clientèle serait désormais à grande majorité orange et non plus verte, la contraignant à plus de justificatifs à apporter pour obtenir un crédit …).
Ceci va nous amener à proposer, en plus des possibilités d’analyse d’impact, une forme de spécification pour les fonctionnalités métiers du produit (non régression) et leurs nouveautés (tickets associés).
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.
