La taverne du testeur

Automatiser les tests d’acceptation ?

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Stratégie

La stratégie au cœur des enjeux qualité – Arnaud Verin

Il m’est arrivé assez souvent de mettre en place, pour des programmes, des stratégies de test avec 40 à 50 phases de test, forcément il faut cadrer les objectifs de chacune pour que le projet de test se passe bien. D’où l’intérêt d’une stratégie de test. La stratégie de test

Lire la suite »
Campagnes

Les étapes d’une campagne de test

Une campagne de test ce n’est pas juste l’exécution de cas de test choisis sans réflexion ni préparation. Avoir une campagne de test efficace demande beaucoup plus. Dans un article précédent j’avais parlé des différentes campagnes de test et de leurs différents objectifs. Dans tous les cas ces campagnes sont

Lire la suite »