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.
2 réponses
C’est un grand débat, et je partage le résultat du match. Le test dépendant du contexte, les deux démarches sont utiles. Pour choisir la stratégie il faut prendre en compte leur destination : qui les exécutera (validation métier ou vérification de la fabrication, niveau de formation comme testeur.se, niveau de formation de l’application sous test), du budget et du délai, si on souhaite les maintenir ou ne les utiliser qu’une fois.
Les tests « par action » sont largement plus adaptés pour des juniors : ils permettent une exécution en autonomie et d’apprendre rapidement ce qui est testé. Mais ils donnent une image « infantilisante » pour des seniors. Par ailleurs cette méthode comporte un risque de faux positifs sur des étapes intermédiaires qui auraient changé, avec tout ce que cela implique (des débats sur des bugs qui n’en sont pas, des oublis sur les étapes suivantes…).
Les tests « par événement » donne des tests plus hauts niveaux au niveau des actions et sont moins adaptés aux juniors. Ils permettent aux concepteurs.ses plus de créativité. Ils sont également plus faciles à maintenir si l’application évolue. En revanche, leur conception et leur exécution s’adresse à des testeurs.ses expérimenté.e.s sur l’application et doté d’une capacité de prise de recul entre ce qui est écrit et ce qui doit être vérifié.
Mon expérience montre qu’ils génèrent beaucoup plus d’échanges pour se faire préciser des étapes/points de contrôles, et que des notions connexes à celles sous test sont souvent abordées. In fine ils contribuent à une montée en compétence plus large.
Enfin, parce qu’elle génère des interactions et des apprentissages, la rédaction « par événement » contribue à une vie d’équipe plus riche ainsi qu’à une motivation plus grande. Donc à choisir quand on peut !
Merci pour ce retour très détaillé
Effectivement le sujet se situe pour moi autour de la professionnalisation / expérience des testeurs