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.
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.
