Je constate assez souvent, lorsque je réalise un état des lieux, qu’il y a autant de façon d’écrire un test que de testeurs en France. Sans aller sur des préconisations d’industrialisation, un sujet ressort assez souvent : la granularité des pas de test.

Ce sujet peut paraitre anecdotique, mais sachant que dans les outils de tests on exécute les pas de test un par un, leur nombre influence un minimum la durée d’exécution, mais surtout la répétitivité du travail et donc la motivation des testeurs. Par ailleurs, dans la plupart des centres de service, les Unités d’Oeuvre sont dimensionnées par rapport au nombre de pas de test des cas de test. La granularité des pas de test influence donc aussi la facture de fin de mois des clients.

De manière générale on retrouve deux types de granularité pour les pas de test : les pas de test par actions et les pas de test par événements.

Pas de test par actions

Un pas de test par action est écrit dès que le testeur fait une action comme remplir un champ, sélectionner une valeur dans une liste déroulante, cliquer sur un bouton… La granularité est donc assez unitaire, et on a en général qu’une seule action par pas de test.

Les cas de test sont alors composés de dix à vingt pas de test voire plus. Il faut donc ouvrir et exécuter les vingt pas de test un par un pour pouvoir réaliser le test dans sa globalité.

En général on a un résultat attendu par pas de test, qui vérifie que le champ qu’on vient de remplir est bien rempli…, engendrant une charge d’écriture importante.

Pas de test par événements

Il est plus compliqué de découper un cas de test par événement que par action. Il faut identifier quand commence et quand finit un événement. En général un événement est caractérisé par le retour d’un traitement informatique tel que l’ouverture d’un écran, le résultat d’un calcul, …

Hors tests unitaires, l’objectif d’un test fonctionnel est de vérifier que les événements sont réalisés tel qu’attendu. Cette granularité se rapproche donc plus d’une réalité fonctionnel-métier.

En retour on a des cas de test composés de trois à cinq pas de test, voire légèrement plus. Il y a donc moins d’étape d’écriture et d’exécution.

Comparatifs

D’un côté plus simple, de l’autre plus efficient, lequel faut-il choisir ?

La manière de découper les pas de test par évènement est moins triviale, et nécessite de meilleurs testeurs, ou des testeurs plus expérimentés. Néanmoins le gain est immédiat avec un nombre de pas de test trois fois inférieur et autant d’interactions, clique souris en moins dans l’outil de référentiel de test.

L’écriture de pas de test par événement nécessite une professionnalisation du métier de testeur, mais comporte de nombreux gains par ailleurs.

Donc pour une fois nous avons un gagnant à notre combat, les pas de test par événement.