Vis ma vie de responsable QA (Part III) – Automatisation des tests

Dans mon article précédent, j’avais prévu de parler de la communication dans l’équipe mais comme je suis agile, je me suis rendu compte qu’un tel article n’apporterait aucune réponse car, après 1 an dans cette équipe et un nombre important d’essais, nous n’avons toujours pas réussi à trouver une communication qui soit efficace et ne soit douloureuse pour personne (rally, mail, oral, board…).

Je vais donc passer directement sur ce 3ème et probable dernier article sur l’automatisation des tests qui étaient, lorsque je suis arrivé, le challenge N°1 du projet.

Watch

5mn de lecture

En fait derrière cette demande, comme souvent, le besoin exprimé n’est pas celui à couvrir. Derrière l’automatisation se cachait l’accélération de la phase de test. Avant que j’arrive, la « phase de non régression » consistant à tester l’application dans sa globalité pour détecter les régressions potentielles prenait 1 semaine d’où le besoin de l’accélérer.

Architecture de test

  • Développement PHP avec plateforme Magento
  • Intégration continue avec Hudson
  • Déploiement automatique sur un serveur d’intégration
  • 2 serveurs de test supplémentaires pour les gros chantiers

L’intégration continue permet, en théorie (et dans mon expérience personnelle), de déployer automatiquement sur un serveur avec une configuration sensée être plus proche de la production qu’une machine de développeur, d’exécuter 3 types de tests: tests unitaires, tests d’intégration et tests d’interface et de créer des packages de déploiement avec un exécutif permettant d’accélérer et assurer les mises en production.

Dans la pratique de ce projet: du déploiement semi-automatisé (c’est la QA qui a la main sur le « build » du projet avec oublis de commit code fréquents), un serveur d’intégration dont la configuration n’est pas proche de celle de la production (certains environnements de devs sont plus proches [chemins d’accès, cache code..]) et des tests unitaires à l’abandon.

Gros chantier que la mise en place de tests automatisés. D’ailleurs, par quoi commencer?

Chantiers

2 sujets en parallèle: remettre en marche les tests unitaires et mettre en place une solution de tests d’interface.

Pour faire court, le sujet des tests unitaire a, lui aussi, tourné court et est tombé dans les limbes des chantiers de développement.

En ce qui concerne les tests d’interface, nous avons cherché un outil qui puisse couvrir des scénarii complexes, qui ne soit pas coûteux à mettre en place, offrant de l’autonomie aux QA.

Plusieurs outils se sont présentés:

  • Selenium en premier lieu car il y avait déjà eu une tentative de mise en place, grâce à  Selenium IDE nous pouvions faire des drafts de scénarii à retravailler
  • Greenpepper offrant un langage de programmation orienté fonctionnel qui aurait permis de traduire directement les User Stories en cas de test voire d’écrire les User Stories avec Greepepper
  • Fitnesse se présentant comme un Wiki et offrant le même intérêt que Greenpepper gratuitement

Nous avons décidé d’investir dans Selenium, Greenpepper étant payant et Fitnesse, à priori, pas toujours mis à jour (mais je connais des personnes qui en sont très contentes).

Selenium

Nous avons binômé avec un développeur afin de créer des scénarii dynamiques permettant la réinjection des tests (il est impossible d’utiliser 2 fois le même mail, retrouver sa commande au fur et à mesure du test…). La technique de développement a permis à la QA, pendant un temps, de modifier facilement le code par rapport aux modifications et finalement de mettre en avant la plus grande barrière à la mise en place du test d’interface: sa propre maintenabilité.

Time To Market

Le projet sur lequel nous travaillons est très hautement piloté par le Time To Market, c’est d’ailleurs la raison principale de la mise en place du projet en mode agile.

Avec nos itérations de 2 semaines + un marché très concurrentiel, les rajouts et refontes sont plus que fréquents. Il n’est pas rare d’avoir sur 2 ou 3 sprints une refonte totale du site. Qui dit refonte graphique ou de workflow dit aussi mise à jour des tests Selenium en conséquence.
Deuxième problème: le développement d’un test peut ne pas être douloureux si le code qu’il doit tester est… testable. En ce qui concerne le test d’interface par exemple: des éléments avec IDs, un code HTML facilement « parsable »… malheureusement, dans notre cas trouver un lien dans le code revenait en XPath à devoir coder des /div[2]/p/div[4]/div[2]/a[5] et si dans le sprint suivant, on demande d’ajouter un nouvel élément dans la page, c’est tout le XPath à revoir… en cascade. Ajouté à ça le temps de réponse des pages, le JS/AJAX et le test devient un risque pour le projet (temps de maintenance, faux négatifs/positifs…)

La remise en cause de l’intérêt du test Selenium dans notre projet a été faite lorsque nous avons découvert un article très intéressant sur le site Selenium To Automate Or Not Automate?
« If an application has a very tight deadline, there is currently no test automation available, and it’s imperative that the testing get done within that time frame, then manual testing is the best solution. »
« Si une application a une deadline très serrée, qu’il n’y a actuellement aucune automatisation de test existante, et qu’il est impératif que le test soit terminé dans ce délai, alors le test manuel est la meilleure solution. »

Après avoir constaté que le test automatisé Selenium n’aurait aucun retour sur investissement pour nous, nous avons décidé de mettre en standby ce chantier et de changer notre fusil d’épaule.

Accélération de la testabilité manuelle

Aujourd’hui la phase de non régression dure 2 jours et évidemment plus le projet avance, plus il grossit, plus il y a d’éléments à vérifier et donc plus cette phase tend s’allonger. Lorsque je suis arrivé, il y avait 8 scénarii de non régression, aujourd’hui nous avons 40 scénarii pour 190 points de vérification et pourtant la phase a toujours duré 2 jours.

Pour arriver à ce résultat, nous avons mis en place plusieurs choses:

  • Documentation exhaustive des workflows du site
  • Raccourcis des process par un système de liens présents sur une seule et même page (rapide et peu coûteux)
  • Mise en place de mock pour les webservices (effectivement, ça aurait pu être fait pour de l’automatisation aussi mais nous avons vraiment appuyé là dessus)
  • Assistance au pré-remplissage des formulaires grâce à GreaseMonkey (tout simplement génial, tout se fait en quelques clics une fois le plugin paramétré sur le navigateur)
  • Toutes les commandes liées à un produit sont accessible dans une vue développeur du back office (quelques clics et une commande passe de « Initiée » à « Terminée »)
  • Et encore d’autres chantiers en préparation…

Effectuer une commande de « bout en bout » est passé de 20mn à 2mn grâce à l’ensemble des outils en place et nous a permis de libérer du temps pour faire d’autres types de vérifications.

Intégration des chantiers de test dans le sprint

Mais tous ces outils doivent être développé, un développeur c’est de la CAF. Nous avons donc décidé de créer des User Stories de testabilité intégrées au sprint et priorisé comme n’importe quelle fonctionnalité, la seule différence c’est que le client, c’est la QA.
Nous avons aussi intégré la création de bouchons/mocks dans les user stories qui nécessitaient le développement de webservices…

Conclusion

Oui le test automatisé est indispensable dans un projet, je reste frustré que personne n’ai senti l’absence de l’exécution des tests unitaires. Par expérience, j’étais déjà conscient de la difficulté à maintenir les tests d’interface même sans time to market.
Je sais aussi, après avoir discuté avec des collègues travaillant dans d’autres contextes, que des solutions existent pour réussir là où nous avons échoué (d’ailleurs si vous avez des solutions n’hésitez pas https://twitter.com/gregalexandre ou par mail g.alexandre[at]coactiv.fr).

Je vais arrêter là cette série de billets, merci de les avoir suivis.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s