Les raisons de l’échec de l’automatisation des tests: des tests qui ne vérifient pas ce qui est désiré

par Marc Hage Chahine | 1 mars 2021

L’automatisation des tests peut échouer pour de nombreuses raisons. Nous allons aujourd’hui nous pencher sur une des causes majeures de ces échecs, les tests qui ne vérifient pas ce qui est désiré.

Avoir des tests qui ne vérifient pas ce qui est désiré aboutit nécessairement à l’échec de l’automatisation

Avant toute chose il est important de rappeler que le problème des tests qui vérifient bien ce qu’il faut n’est pas exclusif à l’automatisation. Néanmoins ce phénomène est plus visible avec cette dernière car lors de l’exécution il n’y a pas un humain derrière l’écran mais bien un robot qui exécute exactement ce qu’on lui dit.

Il existe plusieurs raisons qui font qu’un test ne vérifie pas ce qui est désiré:

  • Une vérification automatique qui cherche un objet qui n’est pas toujours présent
  • Une vérification automatique sur un objet qui est plusieurs fois présent sur la page
  • Une vérification qui cherche un objet qui est bien présent et unique sur la page mais qui apparait sur plusieurs pages
  • Un test mal conçu à l’origine

Le premier point rend le test instable. Il fonctionnera certaines fois et d’autres fois non. On peut par exemple penser à une promotion qui apparait tous les jeudis et qui supprimerait les prix habituels, par exemple pour des pizzas à 5€ au lieu de 10€. Si on fait une vérification sur le prix de 10€ quand on arrive sur la page d’achat des pizzas alors ce prix ne sera pas présent le jeudi et donc le test en échec tous les jeudis.

Le second point est plus compliqué à détecter d’autant plus qu’il est peu probable qu’il arrive manuellement. Toujours sur l’exemple de la promotion, on peut penser à chercher le terme « Promotion » sur la page avec le prix des pizzas le jeudi. De même, rien n’empêche qu’il y ait un autre encart parlant de promotion. Dans ce cas le terme promotion apparait 2 fois. Dans le cas où la promotion du jeudi n’apparait plus, l’automate ne le remarque pas.

Le troisième cas est généralement dû à l’oubli d’un paramètre. Une vérification qui semblait pertinente peut alors ne plus l’être. En gardant l’exemple de la promotion du jeudi, il est facile d’imaginer que le terme de promotion avec le prix de 5€ apparait sur l’ensemble des pages du site ou de l’application le jeudi. Faire une recherche sur ce prix ou le terme « promotion » est alors inutile car il ne prouve rien! Cela revient au même que vérifier que l’url contient bien « www » pour vérifier que je suis sur le site https://www.agilitest.com/.

Le dernier point est simplement dû à des tests mal pensés. Toujours sur la promotion des pizzas. La vérification pourrait être faite sur un élément qui n’a pas forcément de rapport ou qui est éphémère comme une publicité.

Des vérifications pertinentes font des bons tests. Les bons tests sont les matériaux nécessaires pour faire de bonnes campagnes de test. Les bonnes campagnes de tests sont obligatoires pour la réussite de l’automatisation des tests. Il est donc primordial de s’assurer de la qualité de vérifications des tests, que ces dernières assurent bien ce que l’on veut démontrer.

Comment assurer la qualité des vérifications des tests ?

Même s’il est plus important avec l’automatisation, ce problème n’est pas nouveau. Certaines bonnes pratiques sont donc des bonnes pratiques ne sont pas exclusives à l’automatisation, en voici certaines:

La revue des tests

Cette bonne pratique est potentiellement la plus importante car elle permet de recouvrir les 4 points précédents mais aussi d’améliorer de manière générale la qualité des tests. Un point de vue extérieur aide toujours dans son travail! Il est d’ailleurs étonnant que la revue des spécifications et les revues de code soit très développées mais pas encore les revues de test. Les tests sont des livrables conçus et écrits pas des humains. L’erreur est humaine il semble donc évident de faire des revues de test.

Assurer l’unicité d’un objet dans notre recherche

Ce point est primordial! L’objet recherché doit être unique dans l’espace que l’on recherche. Dans le cas contraire son absence ne serait pas remarqué. Agilitest est d’ailleurs un très bon outil pour assurer cette unicité grâce à son outil de capture. En effet, son outil de capture permet de:

  • diminuer la zone de recherche et donc les potentiels parasites ou changements non anticipés
  • Éviter les recherches avec les Xpath peu robustes
  • Assurer l’unicité de notre objet dans notre champs de recherche en 1 clic comme on peut le voir avec cette image:

Exécuter le test plusieurs fois dans des conditions différentes

Faire cela permet de s’assurer que l’objet recherché est bien présent dans un grand nombre de conditions. Pour l’exemple de l’article on peut penser à un test chaque jour de la semaine, avec un compte utilisateur ou non, avec des réductions supplémentaires…

Là encore, Agilitest peut vous aider sur certains points. En effet, la modifications et la gestion des données peut se faire aisément avec l’outil avec la création de csv utilisés pour les données de test.

Vérifier qu’en cas d’erreur le test est en échec

On pourrait rapprocher ce point d’une pratique du TDD qui vise à vérifier qu’un test est en échec avant le développement puis en succès après ce dernier.

Cette bonne pratique est d’ailleurs quelque chose qui devrait être un réflexe car elle tend à démontrer que le test envoie l’information qui est souhaitée. Cela permet d’éviter de nombreux problèmes de manière rapide et efficace.