La taverne du testeur

13 : Concevoir rapidement et progressivement les scénarios de tests d’une fonctionnalité avec l’algorithme des tamis successifs (1 / 3) 

Prenons le cas d’une fonctionnalité “F” du produit et essayons de concevoir des scénarios de test qui pourraient représenter leurs critères d’acceptation.

En termes clairs “F” représente un macro-UC ou un UC (Use Case) du produit à un instant T de sa conception. Autrement dit, “F” intègre et synthétise tous les tickets de réalisation agiles émis sur son périmètre, US et corrections d’US. 

Exemple de la fonctionnalité F modélisée en ATDD

L’algorithme des tamis successifs appliqué à une fonctionnalité F

Voici les différentes étapes de l’algorithme que j’ai créé et expérimenté sur des centaines de projets. Rappelons que cet algorithme est protégé par la marque “Modern Product Agility”.

1. On vise à passer par le chemin nominal (du point d’entrée à un point de sortie)

Il est représenté sur le schéma par les transitions (flèches) en gras, et on choisit les alternatives les plus courantes (marquées en gras).

De fait, on atteint l’objectif de sortie le plus intéressant pour cette fonctionnalité.

Donc ici le chemin est : début, Traitement A, X>=0, Y=1, Z=1 Traitement B, montant ristourne accepté, traitement E, Fin

2. On cherche ensuite à atteindre au moins une fois les autres objectifs (souvent ce sont ceux qui sont portés par les autres points de sortie).

Si on doit repasser dans une transition déjà utilisée, on essaie de passer par une autre alternative de cette transition. Pour les autres transitions (celles nouvelles à traverser), choisir, si possible, les alternatives les plus courantes (c’est un principe général de l’algorithme au passage dans une transition jamais encore utilisée).

Dans notre cas nous aurions :

Ex : Début – Traitement A, X<0, Y=3, traitement D, Feu=Rouge, Fin
Remarque : C’est au Product Owner de décider des objectifs métiers au regard des résultats utilisables pour la suite du processus, l’IT (développeurs/testeurs) proposant des exigences techniques qui influent sur les résultats, donc les objectifs. Nous reviendrons sur ce choix des objectifs ultérieurement. Pour notre exemple nous en resterons à 2 objectifs.

3. On vise à passer par toutes les “boîtes” (traitements fonctionnels et losanges de décision) au moins une fois.

              A ce stade, en effet, on voit que le traitement C n’a jamais été traversé.

              Donc : Début, X>=0, Y=2, Z=2, traitement C, traitement E, Fin

4. Chercher à tester toutes les transitions au moins une fois.

Ici on remarque que les transitions montant ristourne refusé, feu vert, feu orange n’ont jamais été traversées.

D’où les scénarios de test suivants :

Début, traitement A, X>-0, Y=1, Z=1, traitement B, montant ristourne refusé,traitement B, montant ristourne accepté, traitement E, Fin.

Début,  traitement A, X>=0, Y=4, traitement D, feu vert, traitement C, traitement E, Fin

Début, traitement A, X>=0, Y=3, traitement D, feu orange, traitement E, Fin

5. Voir et compléter, si nécessaire, pour tester toutes les alternatives au moins une fois

On remarque que Z=3 est une affirmation encore absente de nos scénarios.

Donc : Début, X>=0, Y=2, Z=3, traitement C, traitement E, Fin

 A ce stade, on peut s’arrêter, en général. 

       Toutefois, a-t-on tout testé du schéma modélisant la fonctionnalité du produit ?

       La réponse est négative.

6. On peut regarder d’abord si la complétude des tests des séquences des transitions d’entrée-sortie à chaque traitement et décisions, quitte à générer de nouveaux scénarios.

Ex : Regardons, à titre d’exemple,  les E/S sur le traitement B. 

Il y a 3 séquences possibles d’E/S :

  • La séquence Z=1, B, ristourne acceptée 
  • Z=1, B, ristourne refusée
  • et ristourne refusée, B, ristourne acceptée 

Elles ont été testées  (et c’est aussi vrai pour tous les autres traitements et décisions).

Un traitement avec 2 transitions d’entrée et 2 de sorties donne 4 combinaisons …

7. Le principe est le même avec les alternatives. Qu’en est-il de la complétude des combinaisons d’E/S des alternatives sur les traitements et décisions ?

Sur la première décision on a 2 alternatives en entrée (X>=0, X<0) et 4 en sorties (Y=1, Y=2, Y=3, Y=4) donc … 8 combinaisons !

Vous constaterez que nous n’avons pas testé certaines … (ex: X<0 et Y=2).

Souvent le PO “taguera” les alternatives suivant qu’elles sont touchées par le sprint en cours de test ou non. De cette manière, il pourra sélectionner sur un modèle, par l’algorithme des tamis successifs,  les scénarios de test des nouveautés ou ceux de la non-régression.

Résumé de l’algorithme


Les 7 étapes majeures de l’algorithme des tamis successifs pour une fonctionnalité avec plusieurs traitements intégré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 *

Interview

Michael Granier: PO et Testeur

Bonjour, qui êtes-vous, quel est votre métier et quelles sont vos activités professionnelles ? Bonjour à tous ! Je me prénomme Michael Granier et suis tombé dans le monde du test il y’a maintenant un peu plus de 10 ans ! Je suis Product Owner / Testeur d’une équipe dont le cœur

Lire la suite »
Interview

Témoignage: La genèse d’un ALM

Bonjour Eric, peux-tu nous présenter ton parcours mais aussi comment t’es venu l’idée de créer XStudio ? Je suis actuellement CEO de la société XQual. Société éditrice d’une solution de Test Management : XStudio. Nous sommes en compétition direct avec HP (Quality Center et ALM) et d’autres acteurs plus modestes pour la

Lire la suite »
BD

[Alerte Qualité] La faute à qui ?

Scénario co-écrit par Zoé Thivet, Dimitri Doye et Marc Hage Chahine Planche à mettre en relation avec les articles: Grâce à qui un produit est-il de bonne qualité ? La faute à qui ?

Lire la suite »