La taverne du testeur

10 : Spécifications graphiques du produit en BML

Rappelons que la spécification des exigences fonctionnelles concerne le produit tel qu’il est ou tel qu’il sera  à l’instant t et donc les artefacts à considérer ne sont pas les tickets de réalisation mais ceux de l’architecture fonctionnelle, par exemple les cas d’utilisation (UC composés de tâches métiers)  ou un parcours client composé de macro-UC (MUC).

BML pour rédiger les exigences fonctionnelles des artefacts métiers 

Prenons l’exemple ci-après pour montrer un exemple BML de cette nature, c’est-à-dire utilisant la palette de modélisation métier que nous avons vue dans un précédent article.

Pour produire progressivement des scénarios de test d’un macro-élément contenant des éléments, ceux-ci ayant déjà été testés, il suffit d’appliquer un algorithme sur les cibles possibles de son modèle graphique.

La forme textuelle, bien que possible, n’est pas utile et efficace pour générer les tests … Nous l’expliquerons avec un prochain article  décrivant “l’algorithme des tamis successifs” pour ces macro-fonctionnalités.

Equivalence d’une modélisation graphique et d’exigences haut niveau

Chaque élément graphique peut donner lieu à une phrase de type “gabarit d’exigence”.

Suivant le gabarit on peut avoir différentes exigences. Par exemple (d’autres choix de gabarit pourrait être possible) :

  • Etant donné que je suis manager, 

Quand j’exécute “Faire le traitement A” 

Alors X est calculé (X>=0 ou X<O)

Les 2 alternatives sont mises en avant par l’analyste, car ces 2 cas sont importants pour la suite de l’exécution du modèle, même si X est calculé et suffit pour le développeur du traitement A.

De plus, ce choix de l’analyste est conforme à la table de décision interne au traitement A. Celui-ci vise in fine le calcul de X et on peut cerner, à ce niveau de détail, 2 “objectifs” importants : X>=0 et X<0, même si en interne du traitement A on a pu tester bien des possibilités pour atteindre ces objectifs.

  • Etant donné que “Faire le traitement A” a été exécuté par le manager

Quand (Y=1 ou Y=2) ET Z=1 

Alors le traitement “faire le traitement B” peut être exécuté

On voit que le modèle graphique est plus compact que l’énoncé des règles métiers textuelles. Le nombre d’exigences textuelles peut en effet devenir important. 

Nous retiendrons donc la modélisation graphique comme support de la réflexion à venir sur les scénarios de test de ces macro-fonctionnalités (scénarios que nous pourrons appeler en agile “critères d’acceptation” …).

Le modèle graphique est autosuffisant

Quand un PO réalise ses tests, il a besoin d’un guide pour son scénario, pas d’une liste détaillée de cas. Il sait prendre de la hauteur et connaît ses applications. Par analogie avec la vie courante, pour aller d’une ville A à une ville B  par les nationales, vous avez besoin de la liste des villes traversées vous permettant de suivre la direction à suivre, même dans les villes, pas d’un roadbook détaillant chaque carrefour !

Le modèle graphique fournit des transitions et des alternatives possibles à utiliser … Il n’est pas nécessaire de documenter en tables de décision supplémentaires à ce niveau. L’agilité prend son sens avec ce formalisme simple : il est auto-porteur pour les métiers.

On n’a besoin d’une documentation de détail que si nécessaire …

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 *

Retour d'expérience

Analyse de mes principales erreurs

Intégrer une nouvelle équipe, inculquer l’esprit du test : Mon expérience et mes conseils. Introduction: A début je voulais présenter cet article comme une liste de conseils pour bien s’intégrer dans une équipe et inculquer l’esprit du test. Finalement j’ai opté pour une présentation plus personnelle avec des exemples de ma

Lire la suite »
culture générale

Ce que je retiens du World Quality Report 2019

Si vous ne connaissez pas le World Quality Report ou les autres enquêtes liées au test, je vous invite à lire mon artcile à ce sujet. Le World Quality Report maintenant disponible et vous pouvez vous le procurer en allant sur ce lien. J’ai pris le temps de le lire

Lire la suite »