Les raisons de l’échec de l’automatisation des tests: un choix d’outil non adapté

par Marc Hage Chahine | 3 mars 2021

L’automatisation des tests peut échouer pour de nombreuses raisons. Nous allons aujourd’hui nous pencher sur une cause récurrente de ces échecs, un mauvais choix d’outil.

Choisir un outil adapté à notre contexte est primordial pour réussir son automatisation

Automatiser ou non ses tests, lorsque l’on travaille en Agile est rarement une question mais plutôt une nécessité. Afin de répondre à ce besoin de nombreux outils existent… Chacun avec ses points forts, ses points faibles mais aussi les compétences et environnements nécessaires à son utilisation!

Les risques les plus courants avec un choix d’outil non adapté sont :

  • L’impossibilité de tester tout ou une partie de l’application. Les outils ne peuvent pas forcément tester toutes les technologies. De même certains objets peuvent ne pas être reconnus par certains outils.
  • Des compétences nécessaires non adaptées aux compétences de l’équipe. Cet aspect est parfois négligé lors du choix d’un outil alors qu’il est primordial. Les personnes qui vont utiliser l’outil ont-elles les connaissances techniques nécessaires pour l’utiliser correctement ?
  • Une rentabilité de l’outil qui n’est pas au rendez-vous. Un outil peut être capable de tester notre application en entier mais avec un coût de mise en place et de maintenance tellement élevé que l’automatisation s’en retrouve inintéressante financièrement. Ce problème peut venir de l’architecture de l’automate mais aussi du fait que l’outil a été trop « tordu » répondre à notre besoin. Attention, le coût d’un outil ce n’est pas uniquement son coût de licence!

Sans étude préalable il est fort probable de tomber sur un « mauvais outil ». Par « mauvais outil » il ne faut pas entendre un « mauvais outil » en tant que tel. Non, un « mauvais outil » est un outil qui n’est pas approprié à notre contexte.

Des outils comme Cypress ou Selenium sont prévus pour faire du test Web et reconnus comme des « bons outils ». Néanmoins si l’on veut faire du test d’application lourdes ces outils s’avèrent inefficaces et donc de « mauvais outils ». De même si les personnes amenées à écrire, exécuter et maintenir les tests ne sont pas techniques, Cypress et Selenium, se retrouveraient également rangés dans la catégorie « mauvais outil ».

Dans les 2 cas proposés (application lourde et équipe peu technique) Agilitest est un outil qui peut répondre au besoin, il est donc, de ce point de vue, un meilleur outil que Cypress et Selenium.

Comment s’assurer de la sélection d’un bon outil ?

Les problématiques liées à la sélection d’un outil d’automatisation sont généralement connues et pour faire le bon choix il faut tout d’abord faire un état des lieux sur nos besoins:

  • Que dois-je automatiser ?
  • Quel est mon budget ?
  • Quelles sont les compétences techniques de l’équipe ? Puis-je avoir des renforts éventuels ?
  • Peut-il s’intégrer à notre environnement de développement et de test ? …

Suite à cette étape nécessaire il est alors possible de faire une étude des outils répondant à notre besoin.

Exemple:

je veux un outil capable de tester différentes applications lourdes et web. Il y a des compétences techniques dans l’équipe mais la moitié de mes testeurs a un profil plutôt fonctionnel.

Suite à ma recherche j’ai repéré 3 outils qui peuvent répondre à mon besoin: XXX, YYY et ZZZ, un outil proposant une forte flexibilité et fonctionnant par mots clés.

Cette étude permet de faire un premier tri en faisant ressortir uniquement les outils intéressants pour notre contexte. Néanmoins cette étude bien qu’indispensable n’est pas suffisante. En effet, même dans le cas où, sur le papier, un outil semble parfait et meilleurs que tous les autres rien ne remplace une mise en situation et le mise en place d’un projet pilote.

Pour cela, il est préférable de sélectionner les 2 ou 3 outils qui semblent le plus pertinents et de commencer à automatiser (pendant quelques semaines) avec afin de voir comment ces derniers s’intègrent et sont utilisés par l’équipe. Cette expérience permet alors de choisir plus facilement l’outil qui correspond le mieux à nos besoins parmi les outils testés (à noter: il est également possible de n’en sélectionner aucun et d’en tester d’autres).

Seule une vraie mise en situation et un vrai pilote permettent de s’assurer que l’outil sélectionné correspond vraiment à nos besoins.

Reprenons l’exemple précédent:

XXX et YYY ont été sélectionnés.

Le projet pilote montre que:

  • la licence XXX est moins élevée que celle de YYY et ZZZ
  • XXX et YYY peuvent automatiser nos tests sur l’ensemble de nos applications
  • La prise en main de XXX est assez complexe et demande plus de formation à l’équipe que celle d’YYY
  • Les testeurs moins techniques écrivent les tests plus rapidement et efficacement avec YYY, ils ne peuvent pas utiliser l’outil ZZZ.
  • YYY est plus cher, mais au final produit des tests qui ne nécessitent que peu de maintenance, ce qui réduit le coût global licences + temps passé de l’équipe par rapport à la solution XXX.
  • ZZZ est gratuit mais peu adapté au projet et difficile à maîtriser.

A final l’équipe choisit YYY pour des raisons ergonomiques mais aussi des raisons de coûts (la différence de coût de licence étant compensée par moins de formation et une meilleure productivité des profils fonctionnels)

Conclusion:

Bien choisir son outil est primordial pour réussir son automatisation. Afin de faire le bon choix il faut avant tout savoir ce dont on a besoin. Suite à cela il faut commencer une étude de marché qui aboutira sur un projet pilote avec le ou les outils qui semblent le plus correspondre à nos besoins. Attention: les outils évoluent, notre application également ce qui fait changer le contexte. Avoir des tests qui ne sont pas totalement dépendants de l’outil d’automatisation est un vrai plus dans notre monde moderne.