Dans la continuité de l’article sur les pas de test, un deuxième sujet ressort assez souvent lors des états des lieux que je réalise : la granularité des cas de test.

De manière générale on retrouve deux types de granularité pour les cas de test : les cas de test par fonction et les cas de test par processus.

Cette fois l’impact n’est pas sur la « pénibilité » d’exécution, mais sur l’efficience du processus de test, au travers de la réutilisation des cas de test, de la capitalisation et de la facilité de gestion.

Cas de test par fonction

La maille est ici la fonction, comme par exemple : Créer une commande fournisseur.

Le problème est que les User Stories ou autre gestion d’exigences ne sont pas à cette granularité, et qu’en l’absence fréquente d’architecte fonctionnel, on n’a pas forcément ce découpage en entrée des tests. C’est alors au testeur d’assumer ce rôle d’architecte…

Une fois qu’on a défini le début et la fin de la fonction, il est alors facile d’écrire le cas de test, et d’en définir les résultats attendus. Ce cas de test est alors facilement duplicable afin de simuler d’autres cas d’utilisation est ainsi d’élargir la couverture des tests.

Cas de test par processus

La maille est ici le processus. Si on prend l’exemple ci-dessus de commande fournisseur, le cas de test serait : Effectuer un réapprovisionnement. Ce cas de test de niveau processus enchainerait donc des étapes de commande, réception, paiement …

Cette granularité se différencie par l’absence de besoin d’architecture. On simule le futur comportement de production sans se soucier de découper les cas de test. Il est donc plus simple de les écrire de cette manière-là.

Ces cas de test représentent un certain enchainement de cas fonctionnel, et il faudra quasiment réécrire chaque cas de test pour avoir la couverture souhaitée. Il est plus compliqué de les réutiliser.

Comparatifs

Plus simple à écrire d’un côté, plus facilement duplicable de l’autre.

Souvent on a entre 5 et 10 cas d’utilisation par fonctionnalité. Si on veut être efficient, il vaut donc mieux écrire des cas de test par fonction pour gérer la couverture de test facilement. Par contre cela nécessite un certain niveau de maitrise d’architecture par le testeur, et milite donc pour une professionnalisation plus poussée du métier de testeur.

Pour imager, si on prend l’exemple précédent d’un processus avec 3 fonctions de 10 cas d’utilisations chacune. Même si les couvertures ne sont pas similaires, d’un côté on a 30 cas de test de niveau fonction et de l’autre 1000 cas de test de niveau processus, pour passer sur toutes les situations fonctionnelles. Les 1000 cas permettent aussi de simuler un bout en bout, mais a-t-on réellement besoin de 970 cas supplémentaires pour gérer ce risque d’anomalie… L’exemple est poussé à son extrême, mais montre néanmoins la problématique.

Dans cet exemple on préférera faire 30 tests fonctionnels et 5-6 tests bout en bout plutôt que de réaliser entre 50 et 100 cas de test de niveau processus. Ce sujet de niveau stratégie de test déborde du présent article, mais permet de bien comprendre le contexte.

Nous avons donc un gagnant dans ce combat, mais un gagnant qui est plus difficile à atteindre …