Mes deux précédents articles, partition d’équivalence et analyse des valeurs limites, se sont concentrés sur la détermination de valeurs pertinentes des entrées d’un logiciel.

Toutefois, ces deux techniques n’ont à aucun moment considéré la combinatoire possible entre ces entrées. Je vous propose dans cet article une technique permettant de répondre à cette problématique de la combinatoire: les tables de décision.

PRÉSENTATION DE LA TECHNIQUE

DÉFINITION ISTQB

Les tables de décision sont utilisées pour tester les interactions entre des combinaisons de conditions.

Les tables de décision apportent une méthode claire pour vérifier les tests de toutes les combinaisons de conditions possibles et pour vérifier que toutes les combinaisons possibles sont gérées par le logiciel testé.

Le but du test par table de décision est d’assurer que toutes les combinaisons de conditions sont testées. En essayant de tester toutes les combinaisons possibles, les tables de décisions peuvent devenir très grandes.

Une méthode appelée « test par table de décision réduite » consiste à réduire intelligemment les nombres de combinaisons à partir de toutes celles possibles vers celles qui sont « intéressantes ». Avec cette technique, les combinaisons sont réduites à celles produisant des sorties différentes, et tous les tests redondants ou irréalistes sont supprimés.

La décision d’utiliser des tables de décision entières ou réduites est en général basée sur les risques.

APPLICATION

Cette technique est généralement utilisée dans les niveaux intégration, système et acceptation. Au niveau unitaire, nous privilégierons une autre technique boite blanche avec les couvertures des décisions et conditions (Voir Syllabus ISTQB niveau avancé analyste technique de tests).

Lorsque les spécifications sont formulées sous forme de règles métier ou de diagrammes de décision, cette technique devient très pertinente. Il est aussi possible de reformuler une spécification pour faciliter la mise en oeuvre des tables de décisions.

LIMITATIONS/DIFFICULTÉS/RISQUES

La plus grande difficulté de cette technique est d’identifier toutes les conditions et d’en définir le résultat. La combinatoire peut vite augmenter et il devient humainement difficile de poser la table de décision dans sa totalité. Vous pouvez vous appuyer sur un diagramme de causes et effets pour construire la table de décision.

Comme toute technique qui réduit la combinatoire, un risque est pris et ce dernier doit être défini et adressé afin de ne pas laisser passer des défauts dont les conséquences seraient inacceptables.

COUVERTURE

Une table de décision est un tableau où chaque colonne est un cas de test.

Pour avoir 100% de couverture de la table, il faut autant de tests que de colonne.

Ce nombre est déterministe car une fois que la liste des conditions est connue, le nombre de cas de test pour avoir 100% de couverture est égal à 2^{nombre de conditions}

TYPE DE DÉFAUT

Lors de la création de la table, des omissions de combinaison peuvent être révélées dans la spécification.

L’exécution des cas de tests dérivés de la table de décision peuvent révéler des défaillances du fait d’une mauvaise combinaison des conditions.

MISE EN ŒUVRE

Comme pour toute technique basée sur les spécifications, la première étape est d’identifier les conditions présentes dans cette dernière mais aussi les actions du logiciel en sortie.

Une fois les conditions identifiés, nous posons la table de décision (comme pour une table de vérité).

Prenons un exemple avec la spécification suivante pour une application calculant le malus à appliquer sur le prix de vente d’un véhicule:

• les véhicules diesel de 10 ans ou plus se voient attribués un malus de 5%.
• les véhicules diesel de moins de 10 ans se voient attribués un malus de 2%.
• les véhicules essence de 10 ans ou plus se voient attribués un malus de 5%.

Nous pouvons en déduire les conditions et actions suivantes:

• décision D1 : est-ce que le véhicule est diesel ?
• décision D2 : est-ce que le véhicule est essence ?
• décision D3 : est-ce que le véhicule a 10 ans ou plus ?
• décision D3 : est-ce que le véhicule a moins de 10 ans ?
• action A1 : est-ce qu’un malus de 2% s’applique ?
• action A2 : est-ce qu’un malus de 5% s’applique ?

Nous commençons à poser la table de décision. Nous y mettons la première décision pour le moment.

D1 (diesel?)	VRAI	FAUX

Puis nous ajoutons la seconde décision D2: le VRAI pour chaque valeur de D1 puis on duplique D1 pour placer le FAUX de D2.

D1 (diesel ?)	VRAI	FAUX	VRAI	FAUX
D2 (essence ?)	VRAI	VRAI	FAUX	FAUX

Nous recommençons la même méthode avec notre décision D3: nous posons le VRAI pour chaque valeur combinée (D1/D2) puis on duplique le tout pour poser le FAUX de D3.

D1 (diesel ?)	VRAI	FAUX	VRAI	FAUX	VRAI	FAUX	VRAI	FAUX
D2 (essence ?)	VRAI	VRAI	FAUX	FAUX	VRAI	VRAI	FAUX	FAUX
D3 (>=10 ans ?)	VRAI	VRAI	VRAI	VRAI	FAUX	FAUX	FAUX	FAUX

Nous ajoutons maintenant nos actions de sortie et nous déduisons de la spécification le résultat attendu.

D1 (diesel ?)	VRAI	FAUX	VRAI	FAUX	VRAI	FAUX	VRAI	FAUX
D2 (essence ?)	VRAI	VRAI	FAUX	FAUX	VRAI	VRAI	FAUX	FAUX
D3 (>=10 ans ?)	VRAI	VRAI	VRAI	VRAI	FAUX	FAUX	FAUX	FAUX
A1 (malus 2%)	ERREUR?	FAUX	FAUX	FAUX?	ERREUR?	FAUX?	VRAI	FAUX?
A2 (malus 5%)	ERREUR?	VRAI	VRAI	FAUX?	ERREUR?	FAUX?	FAUX	FAUX?

Dans cette table de décision, nous pouvons voir:

• ERREUR? : à ce jour, il n’existe pas de véhicule cumulant l’essence et le diesel. Aussi, il conviendra que la conception de l’application prenne en compte cela soit en ne permettant pas la saisie de cette situation ou avoir un mécanisme de vérification et de message d’erreur.
• FAUX? : si nous faisons une lecture implicite de la spécification, nous gardons le FAUX. Sauf que l’implicite n’est pas forcément ce qui est attendu. Il est préférable de le rendre explicite.

Nous avons eu les informations suivantes du métier et de l’équipe de développement:

• Il ne sera pas possible de saisir un véhicule essence et diesel en même temps. Si un utilisateur tente de contourner pour faire une telle saisie, le logiciel rejettera avec une erreur et aucun malus ne sera calculé.
• notre interprétation de la spécification sur les implicites est correcte.

Nous pouvons donc en déduire la table de décision définitive suivante. il nous faudra 8 cas de tests pour la couvrir.

	Test 1	Test 2	Test 3	Test 4	Test 5	Test 6	Test 7	Test 8
D1 (diesel ?)	VRAI	FAUX	VRAI	FAUX	VRAI	FAUX	VRAI	FAUX
D2 (essence ?)	VRAI	VRAI	FAUX	FAUX	VRAI	VRAI	FAUX	FAUX
D3 (>=10 ans ?)	VRAI	VRAI	VRAI	VRAI	FAUX	FAUX	FAUX	FAUX
A1 (malus 2%)	FAUX	FAUX	FAUX	FAUX	FAUX	FAUX	VRAI	FAUX
A2 (malus 5%)	FAUX	VRAI	VRAI	FAUX	FAUX	FAUX	FAUX	FAUX
A3 (Erreur)	VRAI	FAUX	FAUX	FAUX	VRAI	FAUX	FAUX	FAUX

Nous pouvons maintenant décider de réduire la table afin de sélectionner des tests fumigatoires par exemple.

La première étape est d’éliminer les combinaisons impossibles ou incohérentes. Dans notre précédent exemple, nous pouvons dire que si le véhicule est diesel, il ne peut être essence (et inversement) et l’équipe de développement nous a assuré que la conception sera robuste à cette situation. Nous allons donc éliminer ces deux entrées.

La table devient donc:

	Test 2	Test 3	Test 4	Test 6	Test 7	Test 8
D1 (diesel ?)	FAUX	VRAI	FAUX	FAUX	VRAI	FAUX
D2 (essence ?)	VRAI	FAUX	FAUX	VRAI	FAUX	FAUX
D3 (>=10 ans ?)	VRAI	VRAI	VRAI	FAUX	FAUX	FAUX
A1 (malus 2%)	FAUX	FAUX	FAUX	FAUX	VRAI	FAUX
A2 (malus 5%)	VRAI	VRAI	FAUX	FAUX	FAUX	FAUX
A3 (Erreur)	FAUX	FAUX	FAUX	FAUX	FAUX	FAUX

La seconde étape consiste à regarder les actions et nous allons essayer de les regrouper.

Nous avons les tests 2 et 3 qui produisent la même sortie A1=FAUX, A2=VRAI et A3=FAUX et nous pouvons observer que cette sortie ne dépend que de la condition D3.

	Test 2 et 3	Test 4	Test 6	Test 7	Test 8
D1 (diesel ?)	FAUX/VRAI	FAUX	FAUX	VRAI	FAUX
D2 (essence ?)	VRAI/FAUX	FAUX	VRAI	FAUX	FAUX
D3 (>=10 ans ?)	VRAI	VRAI	FAUX	FAUX	FAUX
A1 (malus 2%)	FAUX	FAUX	FAUX	VRAI	FAUX
A2 (malus 5%)	VRAI	FAUX	FAUX	FAUX	FAUX
A3 (Erreur)	FAUX	FAUX	FAUX	FAUX	FAUX

En continuant notre observation, nous avons les tests 4, 6 et 8 qui produisent la même sortie. Mais attention, il faut aussi trouver parmi les entrées de quoi justifier la réduction. Nous en trouvons une avec les tests 4 et 8. En effet, l’age n’influence pas la sortie si le véhicule est ni diesel et ni essence. Une fois ces deux tests réduits, nous ne trouvons pas de quoi discriminer une entrée supplémentaire pour augmenter la réduction avec le test 6. Nous allons donc le laisser.

	Test 2 et 3	Tests 4 et 8	Test 6	Test 7
D1 (diesel ?)	FAUX/VRAI	FAUX	FAUX	VRAI
D2 (essence ?)	VRAI/FAUX	FAUX	VRAI	FAUX
D3 (>=10 ans ?)	VRAI	VRAI/FAUX	FAUX	FAUX
A1 (malus 2%)	FAUX	FAUX	FAUX	VRAI
A2 (malus 5%)	VRAI	FAUX	FAUX	FAUX
A3 (Erreur)	FAUX	FAUX	FAUX	FAUX

En réduisant la table de décision, il nous faut 4 cas de test pour assurer la couverture des 3 actions possibles tout en sécurisant la combinatoire sur les entrées.

CONCLUSION

Cette technique est particulièrement efficace pour réduire la combinatoire et se concentrer sur des cas de tests pertinents. Couplée avec l’analyse des valeurs limites, elle devient très puissante en ciblant des valeurs spécifiques pour provoquer le VRAI ou FAUX des conditions.

Elle assurera aussi un grand rôle dans la relecture d’une spécification et permettre l’amélioration de cette dernière.

Toutefois, si la spécification est complexe, il deviendra difficile d’identifier toutes les conditions et la table de décision va vite devenir illisible et complexe à réduire.

Enfin, comme pour les précédentes techniques, réduire la combinatoire fait porter un risque qualité qu’il convient d’adresser à sa juste valeur selon le contexte.

SOURCES ET REMERCIEMENTS

Le syllabus ISTQB niveau avancé Test Analyste traduit en français par le CFTL

La norme BS-7925-2  « Software component testing standard »

Merci à Marc Hage Chahine pour sa relecture.