Faut-il automatiser ses tests ?

Contexte et enjeux

L’automatisation des tests est un sujet très large dans lequel il est risqué de se lancer les yeux fermés. Avant d’enclencher la machine, il est donc préférable de se poser quelques questions pour ne pas perdre en milieu de course tout ce qui a été créé au début du projet d’automatisation. Les retours en arrière sont souvent très coûteux et difficiles (voire impossible sans repartir de 0) en matière d’automatisation.

Pour établir sa stratégie de test d’automatisation, il est donc nécessaire de se poser les questions suivantes :

Pourquoi automatiser les tests ?

A. Les objectifs de l’automatisation

C’est la première question à se poser ! Si l’on n’a aucun intérêt à le faire, autant rester sur des tests manuels qui présentent l’avantage d’être exécutés par un être humain qui peut s’adapter en temps réel et éviter ainsi les erreurs ou retards de mise à jour/maintenance des tests automatisés.

Toutefois, il existe de nombreuses bonnes raisons de vouloir automatiser ses tests. Celles-ci peuvent se regrouper en 3 catégories qui découlent les unes des autres (clique sur les 3 onglets pour avoir plus d’informations sur chacun de ces objectifs) :

B. Automatisation des tests et agilité : un duo gagnant ?

Vous l’aurez donc compris, l’automatisation des tests est donc une stratégie très intéressante dans la mise en place d’une organisation agile (Scrum, Kanban…) où il est nécessaire de tester plus souvent, plus rapidement un périmètre de test exponentiel avec le temps. L’automatisation permet d’alléger la charge de test sur le périmètre de non régression pour se concentrer sur la nouvelle valeur créée.

Elle devient même quasiment obligatoire dans les approches du type BDD (Behavior Driven Development), TDD (Test Driven Development) ou ATDD (Acceptance test Driven Development) puisqu’elle fait partie de l’ADN de la méthodologie. En effet, ces tests sont automatisés dès leur première exécution lorsque les conditions le permettent.

Cette étape d’automatisation des tests est aussi bénéfique dans la relation entre le QA agile et le développeur. Ces derniers communiqueront en permanence pour créer et anticiper les difficultés de maintenance sur ces tests automatisés.

C. Les tests automatisés peuvent-ils remplacer totalement les tests manuels ?

Attention, tous les tests ne sont pas automatisables !

En effet, les tests automatisés sont un parfait complément aux tests manuels, mais ils ne peuvent pas totalement les remplacer. Il existe certains freins à l’automatisation (cliquez sur les flèches à gauche pour en savoir plus) :

S’il est nécessaire d’insérer une carte bancaire dans un TPE, l’automate de test ne pourra pas réaliser cette action par exemple. De manière générale, ce frein est rencontré lorsque le jeu de données à utiliser pour le test ne peut pas être créé de manière automatisée.

L’automatisation du test a un coût, mais la maintenance peut parfois être encore plus onéreuse que l’étape de conception si le code est en perpétuelle évolution. Même s’il existe des frameworks permettant de limiter les maintenances, il est déconseillé d’automatiser des tests où le code doit gagner en maturité.

Les tests nécessitant une réflexion ou une analyse non prévisible ne pourront pas être automatisés. Tester une sécurité qui demande de sélectionner les photos avec des chats parmi un panel de photos ne pourra pas être automatisé par exemple.

Un automate de test ne pourra jamais réaliser des tests qui se veulent par définition non scriptés. Les tests manuels ne pourront donc jamais être remplacés sur ce type de test.

Quels sont les tests à automatiser ?

A. Les critères du ROI

Il n’existe pas de formule magique dans l’automatisation des tests. Chaque projet aura sa propre formule de réussite. Toutefois, il existe des critères sur lesquels se baser pour la sélection des cas de test à automatiser. Ceux-ci ont tous pour objectif de satisfaire le calcul du ROI (Return On Investment) du projet d’automatisation.

En effet, ce ratio détermine le bénéfice attendu par rapport au capital investi. On va donc chercher à automatiser les tests les plus rapidement rentables. Pour cela, on va donc se baser sur les critères suivants :

Etape 1 Shift Left

Nombre d’exécution
du test

Plus un test sera joué, plus il sera rentable. Ainsi, il est souvent pertinent de prioriser l’automatisation des tests de recevabilité et de non régression.

Etape 2 Shift Left

Faisabilité/complexité technique

Plus un test est difficile à automatiser, plus il sera coûteux de le développer et de le maintenir. Le nombre d’exécutions nécessaires sera donc plus élevé pour un test avec une forte complexité technique.

Etape 3 Shift Left

Maturité
du code

Plus un code est instable, plus il sera nécessaire de le maintenir, et par conséquent, coûteux.

B. Les impacts projets

Si ces 3 précédents critères sont purement financiers, des critères liés au projet sont également à prendre en compte (cliquez sur les flèches à gauche pour en savoir plus) :

Si votre projet adopte une méthodologie agile de type TDD, BDD ou ATDD, il est préférable d’automatiser les tests dès la phase développement. On va donc intégrer l’automatisation sur la majorité des tests du projet.

20% des features d’une appli représentent 80% des features utilisées par les utilisateurs. Ces fonctionnalités étant les plus utilisées, elles doivent être totalement opérationnelles. Elles sont donc la cible privilégiée des tests de non régression et par conséquent de l’automatisation.

Certaines features ont un fort impact financier ou en termes d’image bien qu’elles ne soient pas inclues dans la règle des 20/80. Cela peut être lié à un historique du client sur une activité ou pour répondre à un « besoin vitrine » par exemple.

Dans le cadre d’une release quotidienne, l’automatisation des tests peut devenir obligatoire afin de couvrir un périmètre suffisant pour valider chaque version.

C. L’approche du stratège

La pyramide de test de Mike Cohn est très utile pour bien comprendre cette approche d’automatisation par type de test.

La pyramide de test de Mike Cohn

Les bonnes pratiques liées à cette pyramide sont généralement les suivantes :

  • Tous les niveaux de la pyramide doivent être couverts par des tests
  • Les tests exécutés à l’étage supérieur ne sont pas identiques à ceux des étages inférieurs (pas de doublon)
  • Pour passer au niveau de test supérieur, il faut que tous les tests du niveau inférieur aient été exécutés avec succès
  • Plus les tests sont à la base de la pyramide :
    • – Plus ils sont nombreux à exécuter
    • – Plus ils sont simples et rapides à exécuter
    • – Plus les bugs sont faciles à identifier et à corriger
    • – Plus les tests sont faciles à automatiser

Ainsi, pour optimiser sa stratégie de test, il est donc recommandé d’automatiser en priorité tous les tests unitaires, puis les tests d’intégration, puis les tests d’API avant de terminer par les tests d’IHM beaucoup plus complexes à automatiser et maintenir.

Ce qu'il faut retenir

Avant de commencer un projet d’automatisation, il faut :

PSSST 👀

Cet article vous a plu ❤️ ? N’hésitez pas à le partager pour que d’autres puissent en profiter ! Rejoignez-nous aussi sur Linkedin pour ne rien manquer et suivre notre veille sur les contenus Product & Quality !

Partager sur linkedin
Partager sur twitter
Partager sur email