Dans l’ISTQB on parle de partitions d’équivalence, tables de décisions et transition d’état comme techniques pour définir un périmètre de test. Certains testeurs utilisent une de ces techniques, d’autres plusieurs ou aucune. Qui a raison, quel est la meilleure technique ?
Partitions d’équivalence
Une partition d’équivalence est définie pour toutes les valeurs d’une donnée qui engendrent le même résultat attendu. En dessous de 18 ans on ne peut pas souscrire, au-dessus on peut, il y a donc deux partitions d’équivalence et donc 2 tests à faire (hors tests aux limites, qui sont une sous partie des partitions).
Cette technique de test est principalement utilisée pour les données chiffrées.
Tables de décisions
Une table de décision représente sous forme d’un tableau, l’enchainement des décisions que prend un utilisateur pour réaliser un acte de gestion (une fonctionnalité).
Personnellement je préfère la version arbre de décision qui est moins contraignante en termes d’utilisation et plus facile à lire et donc à utiliser. Les décisions y sont représentées sous forme de branches dans un arbre. Les feuilles représentent donc tous les tests à réaliser.
Transition d’état
Les transitions d’état sont une vue plus dynamique que les deux autres, et représentent sous forme d’un diagramme l’ensemble des chemins que peut prendre un utilisateur pour réaliser un acte de gestion.
Comparatifs
L’ensemble de ces techniques sont finalement basées sur le même élément : les décisions. Et c’est normal, vu que quand on fait du test on simule les différents comportements en production.
Premièrement les partitions d’équivalence ne sont pour moi pas une technique de définition de périmètre de test à proprement parlé, étant donné qu’elle se focalise quasiment uniquement sur les données chiffrées. C’est plus une « bonne pratique » que l’on peut utiliser dans le cadre des deux autres techniques.
Deuxièmement, les transitions d’état représentent tous les chemins, donc les décisions y sont représentées plusieurs fois. Les diagrammes peuvent être difficile à construire et très complexe dès qu’on a plus de 2-3 décisions.
Dans les tables de décisions on n’a certes pas tous les chemins, mais il suffit de remonter l’arbre à l’envers ou d’une autre manière pour les avoir. De plus l’ordre des décisions n’a souvent aucun impact. On a donc une vision plus simple et finalement on a une couverture équivalente.
On a un vainqueur dans ce combat les tables de décision, ou plutôt les arbres de décision.
Les tables et arbres de décision deviennent rapidement compliquées à utiliser quand on a plus de 3-4 règles de gestion pour une fonctionnalité. J’ai donc créé une technique hybride, que j’explique plus en détail dans un précédent article : « Comment bien définir le périmètre de test ».
