Pourquoi Automatiser les Tests de Logiciels ?

Chez wega, un grand nombre d’activités gravitent autour de la validation de logiciels dans le but d’obtenir les preuves formelles du bon fonctionnement des applications utilisées, notamment dans des environnements pharmaceutiques réglementés.

L’une de ces activités consiste à effectuer manuellement des scripts de test, qui sont des pages d’instructions devant être exécutées très précisément, étape par étape.

• Lorsque l’un d’entre nous effectue ce genre de tâche pour la première fois, il en ressort généralement avec des pensées plutôt mitigées :
• Waouw, ce job me demande vraiment toute ma concentration !
• Oh non, je viens de rater l’étape 9…
• Je m’ennuie ; comment cela est-il possible ?! C'est un défi, cela demande une grande concentration, et c'est excitant de découvrir cette application après tout. Mais malgré cela, cette tâche est vraiment fatigante. J'ai l'impression d'être un robot...

Et voilà le mot magique : « Robot » ! Alors automatisons !

Penser à ce qui peut être automatisé ou non, et où les machines peuvent être meilleures que nous s’est révélé être une façon de tester nouvelle et fascinante. Nous avons également commencé à comprendre la différence entre tester et contrôler, comme décrit par exemple sur tutorialspoint.

Tester, en opposition à contrôler, implique d’explorer le système afin d’évaluer s’il se comporte de la façon souhaitée ; si les utilisateurs se sentent à l’aise avec l’outil et que ce dernier leur apporte de la plus-value dans l’exécution de leur tâches quotidiennes, si de potentielles erreurs humaines dans la manipulation du système sont correctement gérées, si la qualité du système est conforme aux attentes, si l'aspect et la prise en main sont attrayants pour l’utilisateur pour, en fin de compte, fournir un retour d’expérience global sur le système testé. Tester est un processus créatif et exploratoire qui requiert du jugement, de l'expérience ainsi que des compétences humaines. Pour l’instant, cela ne peut être automatisé.

En revanche, contrôler consiste à vérifier qu’un système ou l’un de ses composants satisfasse un ensemble défini d’exigences ou de spécifications – dans notre cas, les exigences minimales. Les scripts sont utilisés pour comparer les résultats réels d'un test avec les résultats attendus afin de déterminer si le système fonctionne correctement. C’est donc un processus plutôt structuré et procédural, qui peut par conséquence être exécuté à l'aide d'un outil d'automatisation des tests.

Mais même si une description étape par étape précise dans un script de test peut être automatisée selon cette définition, cela fait-il vraiment du sens ?

Comme souvent, la réponse est : cela dépend – et c'est vrai, cela dépend des objectifs que vous souhaitez atteindre via l’automatisation.

Jusqu'à présent, nous avons fait l'expérience de trois objectifs différents qui pourraient être atteints :

1. La réduction des efforts et des coûts de la phase de test tout en augmentant la fiabilité lorsque le même script de test doit être exécuté de manière répétée, par exemple lors de tests de régression.
2. La réduction du temps d'exécution des tests peut également être intéressante. Prenons l’exemple d’une nouvelle fonctionnalité qui vient d’être mise en place sur un logiciel et doit être testée rapidement, dans ce cas, avoir un script de tests automatisés prêt à l’emploi permet de réduire considérablement le temps d'exécution des tests par rapport à une exécution manuelle.
3. Augmenter la fiabilité et la satisfaction des utilisateurs en mettant en place un système de surveillance. La digitalisation des sciences de la vie conduit à la création d'écosystèmes d'applications qui doivent communiquer plus ou moins en temps réel entre elles. Mais lorsqu'il s'agit d'applications vendues en tant que SaaS (Software as a Service, ou en français : logiciel en tant que service), il devient plus difficile de gérer les mises à jour et leur impact sur l'ensemble de l'écosystème. Si l'on tient compte du fait que des activités informatiques, telles que le déploiement de correctifs ou les opérations de maintenance, peuvent avoir lieu en dehors des heures de bureau, cela représente un grand nombre de facteurs sur lesquels nous n'avons aucun contrôle, mais qui peuvent entraîner l'arrêt complet de processus opérationnels quotidiens cruciaux. Dans un tel cas, la valeur ajoutée de l'automatisation des tests nous semble énorme : il y a certes un investissement initial plus important pour développer les scripts de test qui permettront de couvrir tous les processus cruciaux, mais une fois que cela est en place, rien ne vous empêche de programmer l'exécution de ces tests tous les week-ends, voir même toutes les nuits ! Vous pouvez programmer votre outil pour qu'il vous envoie une notification en cas de détection d'un défaut, ce qui vous permet d'agir en amont ; il est alors possible de résoudre le problème avant même que les utilisateurs ne s'en rendent compte ou, dans le pire des cas, de les avertir que le problème est connu et en cours de traitement, évitant ainsi un grand nombre de demandes de support.

Pour résumer, nous aimerions souligner quelques-unes des expériences que nous avons faites :

• Dès l'écriture des scripts de tests automatisés, il est possible de tester le système de manière très précise. Le script doit être défini dans ses moindres détails, et il n'est pas possible de le décrire de manière plus ou moins précise, comme c'est le cas pour les scripts d'exécution manuelle.
• Les erreurs dans le script de test sont immédiatement détectées : comme l'exécution est très rapide, le script peut être exécuté à plusieurs reprises pour vérifier sa qualité et sa robustesse. En comparaison, les erreurs dans le script pour l'exécution manuelle ne sont détectées que lors des dry runs, qui sont effectués par un testeur parcourant chaque étape et vérifiant qu'elle soit décrite de manière compréhensible et non ambiguë pour l’être humain.
• Et le dernier point, mais non des moindre, est que le développement de tests automatisés est amusant ! En tant que testeur ayant déjà passé des heures à exécuter manuellement des scripts de test, pouvoir observer les déplacements et les clics programmés du curseur ou encore voir une page de formulaire se remplir « toute seule » est une satisfaction toute particulière.