Depuis quelques années j’entends parler d’automatisation des tests « d’acceptance » lorsque j’échange avec des collègues développeurs. D’ailleurs, lorsque l’on fait quelque recherche c’est un type d’article que l’on peut trouver (et très souvent en anglais).
Les tests d’acceptation c’est manuel!
Cette notion de tests d’acceptation (acceptance étant un anglicisme) automatisés est quelque chose qui, je dois l’avouer me laissait dubitatif. Pour rappel, les tests d’acceptation sont des tests fait par des utilisateurs ou leurs représentants et qui ont pour but de valider que le logiciel correspond au besoin. Ces tests sont donc intrinsèquement manuel!
Aucun automate ne peut dire si une nouvelle fonctionnalité et la manière dont elle a été implémentée correspond à ce que recherche quelqu’un et donner son ressenti.
De même, aucun utilisateur ne peut dire à l’avance comment il souhaite utiliser exactement un logiciel avant de l’avoir eu entre les mains… sans compter qu’aucun utilisateur ne sera capable d’exprimer clairement des exigences non-fonctionnelles permettant d’assurer un bon ressenti.
Avec les tests d’acceptation on est clairement sur du « ressenti » du difficilement quantifiable comme peut l’être une « satisfaction ». Cet aspect difficilement mesurable est alors impossible à automatiser car pour automatiser il faut savoir à l’avance ce que l’on va vouloir vérifier.
Les tests d’acceptation sont donc obligatoirement manuels… Et c’est bien pour cela que l’industrie du jeu vidéo (mais pas qu’elle) multiplie des phases de bêta test! Le ressenti du joueur ne peut être anticipé avec des critères fixes définis à l’avance.
Peut-on alors se dire que ce que disent des développeurs très compétents et expérimentés et ce que l’on voit dans les articles est totalement faux ? La réponse est évidemment non!
A quoi correspondent vraiment les tests « d’acceptance » qui sont automatisés ?
Si l’on entend aussi souvent et facilement « automatisation des tests d’acceptance » c’est qu’il y a une raison. Comme souvent la raison trouve son origine dans les termes utilisés.
Dans notre cas ce qui, à mon sens, crée cette « erreur » (un usage est-il vraiment une erreur ?)… ou plutôt ce qui fait que j’étais incapable de trouver les arguments pour faire changer d’avis mes interlocuteur, c’est l’Agile et les critères d’acceptance des US!
J’ai mis beaucoup de temps à m’en rendre compte mais au final la racine de ce mélange des termes vient des critères d’acceptation! Les critères d’acceptation d’une US sont généralement composés de tests définis à l’avance! C’est ces tests qui peuvent être automatisés. Ces tests étant des critères d’acceptation le rapprochement étymologique vers tests d’acceptation est très rapide… voir immédiat.
Je m’en suis rendu compte en travaillant sur le BDD à la définition de ces tests d’acceptation mais surtout en échangeant avec un coach Agile qui propose de belles formations BDD. Dans sa présentation il montre le BDD au niveau « tests d’acceptance ». J’ai évidemment « tiqué » sur ce point et nous avons longuement discuté. C’est à ce moment là que j’ai compris que ce qui est souvent vu et décrit comme « tests d’acceptance » c’est les tests des critères d’acceptation des US qui se trouvent être des tests niveau système… Et les tests système sont des tests qui peuvent évidemment être automatisés car ils vérifient des spécifications.
Si on se penche un peu plus vers le BDD il est d’ailleurs tout à fait logique et fréquent d’automatiser ces tests qui peuvent se retrouver devenir une documentation vivante… et donc les spécifications du produit.
Conclusion
Comme souvent, les incompréhensions viennent de notre langage. Mon erreur a été de trop me référer à l’ISTQB en échangeant avec des professionnels du logiciel non testeurs. Cette erreur m’a empêcher de comprendre pendant environ 2 ans le principe même de collègues très compétents lorsqu’ils me parlaient d’automatisation des tests d’acceptance.
L’Agile engendre de grands changements. Certains de ces changements font que les développeurs et d’autres non testeurs s’intéressent au test et discutent de notions autour de celui-ci. C’est évidemment une très bonne chose qui, en plus d’améliorer la qualité des produits, crée des ponts entre les différents métiers. Ces modifications sont cependant également source de modifications terminologiques comme le montre cet exemple avec l’automation des tests d’acceptance qui s’avère être une automatisation de tests système d’un point de vue strictement ISTQB.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
