Automatisation des tests : doit-on tout automatiser ?

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.
 

Pourquoi automatiser les tests ?  

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. Ce qui permettra de 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/devoir automatiser ses tests. Celles-ci peuvent se regrouper en 3 catégories qui découlent les unes des autres :  

Optimiser la couverture de test

Les tests automatisés permettent de couvrir la non régression pendant que les tests manuels peuvent se concentrer sur les nouvelles fonctionnalités du sprint, les fonctionnalités non automatisables ou des cas de tests bien spécifiques.

Optimiser la qualité des développements

En testant plus souvent un périmètre plus important, la stabilité du code et des développements s’en retrouvent de meilleure qualité.  

Optimiser la durée des cycles de développement

Les tests automatisés étant effectués plus rapidement que les manuels, et pouvant être exécutés simultanément ou en horaire décalé, il devient possible de couvrir plus rapidement le périmètre des tests nécessaires à la Definition of Done (DoD) des US (User Story).
‍

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 une organisation agile (Scrum, Kanban…) où il est nécessaire de tester plus souvent et plus rapidement. Ainsi, elle permet d’alléger la charge des tests manuels sur un scope qui est de plus en plus large.

L’automatisation 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 des tests.

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 :

Les étapes de test non automatisables :  

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éé ou réalisé de manière automatisée.

• L'instabilité du code :  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é. ‍
• Un ordinateur reste binaire : 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.

Et le test exploratoire dans tout ça ?  

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 ?  

Sélectionner les tests à automatiser en fonction des 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 tu peux te 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 rentables. Pour cela, on va donc se baser sur les critères suivants :

• Le 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. ‍
• La faisabilité/complexité technique : plus un test est difficile à automatiser, plus il sera coûteux de le développer et de le maintenir. Dans ce cas, et même si le nombre d’exécution nécessaire pour un test complexe est élevé, il est préférable de consacrer du temps pour le tester manuellement. ‍
• La Maturité du code : plus un code est instable, plus il sera nécessaire de le maintenir, et par conséquent, coûteux.

Sélectionner les tests à automatiser en fonction de l'impact sur le projet  

Si ces 3 précédents critères sont purement financiers. Des critères liés au projet sont également à prendre en compte :

• ‍L'organisation du projet : 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 de développement. On va donc intégrer l’automatisation sur la majorité des tests du projet.
• La règle des 20/80 : 20% des fonctionnalités d’une appli représentent 80% des fonctionnalités 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.   ‍
• Les fonctionnalités à fort impact business : certaines fonctionnalités 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 concerner l’historique du client sur une activité ou un « besoin vitrine » par exemple.
• La cadence des tests : 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.
• 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.
  ‍

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.

‍

Pour conclure, 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 sur l'automatisation des tests

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

• Définir les objectifs de l’automatisation.
• Définir le périmètre à automatiser. 
• Vérifier la rentabilité en fonction des contraintes du projet.