La taverne du testeur

9 : Avantages de BML

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 :

QuandXYAlorsZdirection(par défaut étape suivante)
Etape E1 RG1X=0 OU X compris entre 10 et 20 (bornes comprises)Y >0 quelconque Z non modifié
RG2X est dans l’intervalle (1,9)Y=0Z = 2*Y
Etape E2 etc.
Deux RG formant l’étape 1. Celle-ci a-t-elle une spécification consistante ?

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

certifications

Avis de recherche: paradoxe du pesticide

Pour ceux qui ont lu le syllabus ISTQB fondation v4.0 vous avez sûrement remarqué une absence de marque! Je parle bien sûr du 5ème principe du test: le paradoxe du pesticide! Vous me direz qu’il est quand même surprenant qu’une des « bases du test », érigé en principe fondateur disparaisse comme

Lire la suite »
Agilité

Le rôle de test manager dans les projets en mode agile.

Le test manager ou chef de projet test Le rôle de test manager ou chef de projet test est un métier du test à part entière et est reconnu comme tel. Ce métier fait d’ailleurs l’objet d’une fiche métier et même d’une certification ISTQB niveau 2. Quel est le travail

Lire la suite »
culture générale

Testons les principes du test!

Je ne vais pas y aller par 4 chemins, pour moi s’il y a une chose à retenir dans le monde du test, c’est les 7 principes. C’est un peu notre manifeste Agile à nous, nos valeurs, notre phare qui permet de faire des choix aussi efficients que possible. Néanmoins,

Lire la suite »