Osez l’automatisation des tests

Osez l’automatisation des tests

Les tests fonctionnels indispensables mais coûteux

Les tests fonctionnels sont un excellent processus de test exhaustif qui parcoure toutes les couches d’une application. Toutefois, pour s’assurer de l’absence des anomalies, il est nécessaire de réitérer la totalité des tests suite à chaque évolution de l’application. L’exécution manuelle des tests fonctionnels d’une application en perpétuelle évolution, est longue et assujettie aux erreurs humaines. En outre, ce processus coûteux, bien qu’il soit nécessaire pour assurer la qualité de l’applicatif, il pousse souvent les organisations à s’en passer, l’exécuter partiellement ou – dans les meilleurs des cas – fixer un cycle de release assez long laissant le temps nécessaire aux tests et validation. Cette dernière alternative assure la qualité de l’application mais diminue considérablement sa compétitivité : Un bon compromis serait d’investir dans l’automatisation des tests fonctionnels. Dans ce qui suit nous étudierons les types d’outils d’automatisation disponibles et justifierons le choix porté sur l’un d’eux.

BANNIERE_ARTICLE_v08122017
Fondative opte pour Codeception

Le besoin de Fondative consiste à automatiser les tests fonctionnels et les tests d’acceptation en se basant sur des outils open-source. Une étude minutieuse nous a permis de pointer les outils et les concepts existants. Deux catégories d’outils sont disponibles :

  • Enregistrement et ré-exécution des scénarios : exemple Selenium IDE.
  • Exécution des scripts : Ce type utilise principalement Selenium2 (Selenium et WebDriver), exemple Codeception et Behat.

Le tableau suivant dresse un listing comparatif de leurs principales caractéristiques :

  Selenium IDE Behat Codeception
Reporting Seulement le résultat de l’exécution est fourni (-) Seulement le résultat de l’exécution est fourni (-) Plusieurs informations sont fournies : temps d’exécution, statistiques (+)
Réutilisation et ajouts des nouvelles méthodes Difficile de modifier les scénarios et de réutiliser des portions du code (-) Possible de créer des méthodes et des fonctions pour les réutiliser (+) Possible de séparer totalement entre la conception des pages et les fonctions à réutiliser (+)
Simplicité L’utilisateur ne doit que lancer l’extension et ré-exécuter les scripts (+) La syntaxe ressemble au langage naturel mais pour créer des nouvelles opérations il faut maîtriser le langage Gherkin (-) La syntaxe ressemble au langage naturel mais pour créer des nouvelles opérations il faut maîtriser ce langage PHP (-)
Support des appels synchrones et Upload fichiers Il ne supporte pas les appels Ajax et l’upload image (-) Il supporte les appels Ajax et l’upload image (+) Il supporte les appels Ajax et l’upload image (+)
Support des Frameworks PHP Il ne supporte pas les frameworks PHP (-) Possible de l’intégrer dans des frameworks PHP tel que Symfony (+) Possible de l’intégrer dans des framework PHP tel que Symfony (+)
Support des outils d’intégration continue Il n’est pas supporté par les serveurs d’intégration continue (-) Il peut être intégré avec un serveur d’intégration continue (+) Il peut être intégré avec un serveurd’intégration continue (+)
Support JS avancé Il ne supporte pas les opérations JS avancées (-) Dépend du serveur d’exécution choisi Dépend du serveur d’exécution choisi

L’étude comparative précédente a mené vers le choix du framework Codeception (qui constituera le noyau de la solution d’automatisation des tests Fondative) pour les raisons suivantes :

  • Codeception est le plus riche en termes de fonctions de test.
  • Il fournit des données pertinentes dans ses reportings mis à part les résultats d’exécution.
  • Il est mieux configurable que les autres et on peut l’adapter aux besoins spécifiques.
  • Le framework est bien documenté et supporté.
  • Ecrit en PHP, la création des scénarios est très simple.
Codeception & applications Symfony : l’automatisation à portée de main

Fondative s’intéresse en particulier à automatiser les tests pour ses applications Symfony. Ce framework présente déjà 2 classes natives permettant l’automatisation : il s’agit de sfBrowser et sfTestFunctional. Les fonctions basiques de ces classes ne répondent pas directement aux exigences des tests d’acceptation. Exemple : pour un scénario de renseignement des champs d’un formulaire, il n’existe pas de méthode toute prête permettant l’exécution de ce test ; le développeur est amené à écrire la fonction correspondante. Par contre avec Codeception, il existe une fonction « fillField » où il suffit de passer les noms des champs et les valeurs en paramètres pour que le test soit exécuté. Cette limite fait de Codeception la solution la plus adéquate à l’automatisation d’une application Symfony, il fournit des classes couvrant mieux les besoins des deux niveaux de test (fonctionnels et acceptation).

BANNIERE_ARTICLE_v08122017
Codeception, loin de répondre à tous les besoins

Malgré qu’il s’agit de l’outil le mieux adapté au besoin de Fondative, certaines limites ont été constatées :

  • Traçabilité : Codeception n’a pas d’interface graphique, il n’enregistre que l’étape n-1 donc ne fournit pas d’historique d’exécution complet.
  • Emailings automatiques : Il ne supporte pas la gestion des e-mails.
  • Mono-tâches : Le fichier de configuration de ce framework ne peut gérer qu’un un seul projet à la fois.

Afin de pallier ses limites, l’équipe Fondative a développé une API Rest permettant l’interfaçage entre le front end (interface utilisateur) d’une part et le reste des composants de l’autre part (Codeception, serveurs) d’où on a :

  • Traçabilité : Lors de chaque exécution, les résultats sont enregistrés en base pour être consultables à n’importe quel moment ultérieur.
  • Emailings automatiques : Avoir recours au serveur MailCatcher et création des fonctionnalités nécessaires.
  • Mono-tâches : Modifier la configuration des dossiers de Codeception de façon à permettre l’exécution sur plusieurs projets en parallèle.
Attention ! L’automatisation n’est pas toujours justifiée

Ce choix ne doit pas être opéré systématiquement, il est parfois plus rentable de dérouler les tests, aussi bien que les itérations manuellement, que d’investir dans un développement coûteux d’automatisation. L’application doit remplir 3 conditions principales afin d’être éligible à l’automatisation :

  • Un nombre important de scénarios exécutables.
  • Une grande partie de l’application est stable fonctionnellement : ne pas avoir à ré-écrire les tests chaque fois que le fonctionnement est modifié.
  • Une application évolutive : d’autres modules sont à développer.

Coopérons! : Durée d’exécution des tests divisée par 4

Pour le cas des tests Cooperons! les problématiques rencontrées sont les mêmes décrites au début de l’article en plus d’une autre particularité : On a besoin d’effectuer des mises en production fréquentes et livrer de nouvelles releases sur des intervalles rapprochés (parfois d’une façon hebdomadaire). Sachant que l’exécution de tout le cahier de test est effectuée par 3 testeurs/développeurs et nécessite entre 4 et 5 jours pour être finalisée. On a fini avec des deadlines non respectés et un processus de test plus lent et moins fiable. L’automatisation s’impose dans un tel cas. Les résultats obtenus sur Coopérons! grâce à l’automatisation ont permis de :

  • Obtenir des résultats plus fiables à travers la ré-exécution des scénarios dans des conditions identiques.
  • Accélérer le développement des nouveaux modules grâce à la libération des ressources et au temps gagné.
  • Garder une visibilité totale et permanente sur l’historique des exécutions.
  • Assurer l’exécution automatique de tout le cahier de test sans intervention humaine.
BANNIERE_ARTICLE_v08122017

Laisser un commentaire