Le test est une enquête qui nous permet d’en apprendre plus sur le logiciel que l’on développe. On recherche les problèmes qui menacent la valeur du produit. Avec les informations obtenues, l’équipe chargée de la conception peut ainsi savoir si elle développe le bon logiciel, c’est-à-dire le logiciel auquel elle s’attend et prendre des décisions quant à la qualité.
Dans cette quête d’informations, les tests automatisés ont trouvé toute leur place. Ils se sont démocratisés grâce à des outils comme Selenium. Les concepteurs d’applications sont aujourd’hui nombreux à avoir recours à ces outils et le rôle « d’automaticien des tests » s’est répandu. Dans un marché où il faut se démarquer de ses concurrents et ne pas se laisser distancer, avoir un retour rapide et qui permet de gagner en confiance est essentiel.
Les tests automatisés sont principalement utilisés pour faire du fact-checking. Ils vérifient un comportement auquel on s’attend déjà. On les appelle aussi tests de bout en bout ou end to end tests (e2e). Un test e2e correspond à une tâche qu’un utilisateur peut effectuer via l’interface graphique. Ces tests permettent de détecter des problèmes auxquels les utilisateurs auraient été directement confrontés.
Contrairement aux tests unitaires qui sont destinés à contrôler le comportement des plus petites unités du code (méthodes, classes) et qui sont fortement couplés au code, les tests de bout en bout permettent de contrôler l’ensemble de l’architecture du logiciel (interface utilisateur, base de données, backend, applications tierces, serveur…). En se positionnant au niveau des utilisateurs, ils permettent de contrôler des scénarios complexes qui peuvent couvrir des modules différents du logiciel. C’est se qui fait la force des tests de bout en bout.
Il est intéressant de les utiliser pour couvrir les cas d’utilisation de base sur les fonctionnalités clés du logiciel. Les tests automatisés doivent servir à protéger ce qui important pour les utilisateurs et ce qui fait la valeur du produit pour eux. Il faut donc s’intéresser à comment les utilisateurs se servent de l’application pour être en mesure de concevoir des tests automatisés pertinents.
Lorsque l’on vient de faire des modifications dans le code ce que l’on veut savoir c’est s’il y a des régressions. Pour obtenir cette information on pourrait demander à un testeur d’exécuter lui-même les cas de test un par un. L’inconvénient majeur est qu’il faut beaucoup de temps pour venir à bout de tous les scénarios. De plus, on monopolise un testeur dont les compétences pourraient être bien mieux employées.
Les tests automatisés nous permettent d’avoir cette information beaucoup plus rapidement. D’abord car ils interagissent plus vite avec l’interface que ne le ferait un humain, mais c’est surtout la possibilité de paralléliser leur exécution qui permet de réduire drastiquement le temps d’exécution. Avec un outil comme Selenium Grid l’on peut exécuter en même temps les tests e2e sur de multiples plateformes. Il est aussi possible de multiplier les environnements avec selenium-docker. En plus de faire gagner un temps précieux, les scripts peuvent être joués sur différents systèmes d’exploitation, navigateurs ou équipements (ordinateur, smartphone, télévision…)
Dans un environnement d’intégration continue, comme Jenkins, les tests peuvent être lancés aussi souvent que nécessaire et donc nous tenir informés de la présence de régressions dans les scénarios testés. Il est possible de déclencher l’exécution des tests manuellement, à des horaires programmés ou bien lorsqu’un changement a été effectué dans le code. La création d’un rapport par l’outil d’intégration continue facilite l’accès à l’information (présence de régressions, durée d’exécution, stabilité, nombre de tests…).
Les tests de bout en bout peuvent aussi être associés à des scénarios écrit en langage Gherkin. Il permet d’écrire des scénarios en langage naturel (français, anglais…) et donc d’impliquer dans la rédaction de ces tests des profils qui n’ont pas de compétences en développement (chef de produit, chef de projet, expert métier…). C’est ce que l’on appelle du Behavior Driven Development (BDD). Ces scénarios écrits en langage naturel permettent une compréhension plus rapide de ce que le scénario doit faire et peut servir de documentation sur le comportement attendu du logiciel.
Un point qui a toute son importance est que les tests automatisés permettent au testeur d’être plus efficace. Un produit bien contrôlé par les tests automatisés permet de tester plus rapidement, plus efficacement et plus profondément. En passant les scripts avant que le testeur ne commence une session de test, on réduit le risque que ce dernier perde du temps à travailler sur une version qui contient des régressions. Grâce à ces contrôles préliminaires la confiance est plus grande et le testeur peut alors se consacrer à des activités qui permettront d’évaluer le produit. On peut citer l’analyse de risques, la conceptions des tests, la préparation de jeux de données, le test exploratoire, les expérimentations, les échanges avec les développeurs, la documentation…
Les tests automatisés peuvent aussi être utilisés pour faire du monitoring en production. Les administrateurs systèmes et réseaux peuvent ainsi les utiliser pour savoir si un service fonctionne toujours comme attendu. En programmant un lancement régulier des tests ils peuvent être alertés en cas de dysfonctionnement et intervenir pour rétablir le service. Cette démarche s’inscrit pleinement dans le mouvement Devops.
Pour être un succès, un projet d’automatisation ne doit pas être mené à la légère. Il implique des compétences en management, en test et en développement et il ne faut pas négliger le coût de la conception et de la maintenance des tests. L’obtention d’une couverture satisfaisante demande un investissement important. Si le projet est correctement mené, l’on obtient un outil qui nous aidera à préserver la qualité du produit et la satisfaction des utilisateurs.