Les 9 inconvénients des tests automatisés en projet web


Les 9 inconvénients des tests automatisés en projet web
 

Lorsque l’on analyse une solution qui répond à un besoin que l’on a, on regarde souvent les avantages de cette solution pour se convaincre que c’est la bonne. En réalité, pour savoir si c’est réellement la bonne solution pour nous, il faut également se pencher sur ses inconvénients et sur notre capacité à les contourner. Cette anticipation peut éviter bien des mauvaises surprises…

Ainsi, dans le cadre d’une démarche qualité, lorsque l’on est en réflexion sur l’intérêt de l’automatisation des tests fonctionnels dans un projet web, cette approche s’avère très intéressante.

Automatiser des tests fonctionnels web présente des avantages indéniables pour la qualité globale, pour l’équipe et pour l’entreprise en général. Mais au-delà de tous les bénéfices, il faut également avoir conscience de ce qu’on peut appeler des inconvénients, et qui sont, en réalité, surtout, des points d’attention.

Il est utile de les connaître, sage d’en mesurer les conséquences et judicieux de les affronter pour qu’ils ne deviennent pas un poids trop lourd à long terme.

 
 
   
   l

1- Un test automatisé n'est pas forcément identique à un test manuel

Un test fonctionnel web est une suite d’actions effectuées dans un navigateur.

Pour être pertinent, il est important que le test automatisé réalise les actions de la manière la plus proche possible de celle utilisée par l’utilisateur final. Le choix de la méthode de réalisation d’une action constitue un premier point d’attention.

Par exemple, dans un navigateur il y a souvent plusieurs manières de réaliser une même action. Un clic peut être réalisé à la souris, au clavier ou même en commande vocale. Le téléversement du fichier peut être réalisé par navigation locale puis par sélection du fichier ou par glisser / déposer.

Et à côté de cela, l’automate peut disposer de ses propres méthodes pour simuler ces actions et toutes ne seront pas forcément pertinentes selon le contexte.

Pour faire simple : automatiser c’est bien, mais bien automatiser c’est mieux !

Et c’est à chacun de bien définir dans son propre contexte, le degré de similitude requis entre l’exécution automatisée et l’exécution manuelle.

 
 

2- Un test automatisé peut-être moins précis qu'un test manuel

Un test automatisé intègre également des vérifications utiles permettant de valider la conformité avec les résultats attendus.

Dans le cadre d’un test manuel, effectué par un être humain, ces vérifications utiles sont généralement implicites et réalisées spontanément. Par exemple, l’œil humain va analyser naturellement la dynamique d’affichage des éléments, la présence de l’ensemble des éléments composant la page ou encore l’absence d’éléments indésirables.

Pour un automate, c’est très compliqué de parvenir à ce degré que qualité dans la vérification. Les seules vérifications que l’automate effectuera seront celles qu’on lui aura programmé de faire. Et toute la difficulté consiste à passer d’une liste de vérifications gigantesque faite naturellement par le cerveau humain à une liste finie de vérifications préétablies que doit exécuter la machine.

Là encore, l’indice qualité attendu doit être défini clairement, il fait partie de la stratégie qualité. On peut comprendre qu’il y ait moins d’exigences sur le rendu visuel pour une application de back-office que pour un site de e-commerce grand public.

Par ailleurs, il existe aujourd’hui des solutions, y compris pour satisfaire des exigences fortes en termes de rendu visuel. On pourra par exemple exploiter la comparaison des captures d’écrans obtenues avec celles d’une base de référence.

On retrouve alors le principe de juste qualité consistant à déployer les forces nécessaires et suffisantes pour atteindre le degré de qualité exigé pour satisfaire le client.

 

3- Les tests automatisés ne testent que les cas connus

L’automate de tests ne peut réaliser que des scénarios qu’on lui a programmés. Certes il peut exécuter un même test dans de nombreux contextes différents. C’est ce qu’on appelle des tests combinatoires, mais il n’y a pas de place au hasard.

Il est incapable de réaliser des tests exploratoires, contrairement au testeur manuel qui sait faire preuve de sérendipité en partant à la découverte du produit, pour détecter des bugs, par hasard.

Néanmoins, si l’automate de tests n’est pas (encore) capable de se comporter comme un être humain et d’exploiter un sens critique, il peut évoluer ! S’adapter à une situation inconnue et détenir un pouvoir de décision, voilà le propre de l’intelligence artificielle (IA). Le domaine de la qualité logicielle est donc un client idéal pour cette révolution technologique.  

 
 

4- Un test automatisé est soit trop simple soit trop compliqué

Un test automatisé, pour exister, nécessite d’être créé.

Plusieurs solutions existent pour cela.

On peut le développer dans un langage de programmation. Cela nécessite alors des compétences en développement et le projet va donc demander un investissement important pour assurer la charge inhérente à ce développement.

On peut le créer grâce à des outils qui permettent d’enregistrer chaque étape d’un scénario exécuté en live dans un navigateur. On parle de mode Record and Replay (enregistre et rejoue). Cela est accessible aux non développeurs mais présente l’inconvénient d’être statique et de manquer de souplesse. Le scénario n’est pas configurable après création et ne permet pas de configurer des vérifications requises.   

Pour contrer ces points, on trouve à présent des solutions comme HorusTest qui permet de créer des tests automatisés sans compétences techniques, offrant souplesse et dynamisme.

 

5- Les tests automatisés sont difficiles à maintenir

Quand le produit évolue, cela va inévitablement casser les tests automatisés. Il faut donc, à chaque nouveau développement sur le produit, mettre à jour la base de tests automatisés afin qu’ils restent fonctionnels.

Maintenir la base de tests à jour nécessite d’investir du temps et de mobiliser des ressources pour suivre les évolutions.

Selon la solution adoptée pour automatiser et organiser les tests, la maintenance des tests peut être plus ou moins complexe et plus ou moins chronophage.

 

6- L'environnement d'exécution de tests est coûteux à maintenir

Afin qu’un test automatisé puisse être exécuté, cela nécessite de mettre en place un environnement d’exécution dédié, composé des machines et des systèmes ciblés.

Mettre en place et maintenir la stabilité de cet environnement complexe ainsi que le maintenir à jour des dernières versions représente une charge de travail non négligeable dont il faut avoir conscience.

Heureusement, pour palier ce point, il existe des services Cloud qui proposent ce genre de fonctionnalités, clé en main.

 

7- Les tests automatisés ne sont pas développés par les experts métier

Qui, au sein de l’entreprise, est le plus à même de déterminer la liste des actions et des vérifications qu’un test automatisé doit effectuer ? Les experts métier bien sûr ! Chef de produit, Product Owner, testeur fonctionnel etc.

Pourtant généralement, ils ne sont pas en mesure d’automatiser les tests, ne disposant pas des compétences techniques nécessaires. Les tests sont donc créés par un technicien, qui à l’inverse est plus expert technique qu’expert fonctionnel.

Cela expose deux points d’attention.

Pour être pertinent, il est essentiel que la conception des tests automatisés soient assurés en prenant soin d’impliquer les experts métier.

Et s’ils sont créés par l’équipe de développement, parce qu’elle a l’expertise métier suffisante, cela requiert de lui allouer les ressources nécessaires à cette tâche et d’intégrer cette charge dans la charge prévisionnelle du projet. Il en va de la qualité globale du produit.

 

8- En cas d'échec, l'analyse des résultats peut-être fastidieuse

Les tests automatisés ont pour objectif de détecter des régressions en phase de validation, d’où leur nom de tests de non régression. Et en cas de régression, il est important de comprendre rapidement pourquoi le test a échoué afin de remonter, à l’équipe de développement, les informations utiles à la correction.

Deux choses sont importantes par rapport à ce point.

Les tests automatisés doivent être bien conçus. Idéalement, un test automatisé ne doit tester qu’une seule exigence de telles sortes que si le test échoue, l’on ait directement l’indication de l’exigence impactée.

Et les rapports d’exécution doivent être suffisamment clairs pour que la cause du problème soit rapidement identifiée.

 

9- Les tests automatisés ne peuvent pas être créés en même temps que le développement

En méthodologies Agiles, les développeurs ont à disposition la méthode TDD (Test Driven Development) qui invite à écrire les tests unitaires (TU) avant de produire du code. Cette méthode très rigoureuse et efficace n’est malheureusement pas transposable aux tests fonctionnels.

Pour créer un test fonctionnel automatisé, il est nécessaire que l’exigence fonctionnelle soit disponible dans le produit et donc que son développement soit finalisé.

Ce point d’attention pousse à bien prendre en compte le temps de développement des tests automatisés lors du chiffrage d’une évolution ou d’une nouvelle fonctionnalité. En réalité, il s’agit surtout d’une bonne pratique à adopter puisque selon l’outil choisi, le temps pour automatiser un test n’est pas beaucoup plus long que le temps nécessaire à la réalisation du test.

 

En conclusion, l’automatisation des tests fonctionnels, si elle offre des avantages certains, nécessite de porter attention à plusieurs points qui pourront guider dans le choix de la solution et des bonnes pratiques à adopter.

 
 
Stéphanie Binet
Stéphanie Binet

Experte en qualité web, fondatrice de Gonogo Consultech : conseil en stratégie web et fournisseur de la solution HorusTest.
Optez pour une stratégie qualité pérenne ! HorusTest permet de créer et de gérer vos tests automatisés simplement, sans écrire une seule ligne de code et sans compétences techniques.

Découvrir Horus Test

Commentaires


Laisser un commentaire