La qualité chez Ekwateur, Suite…

Savoir que notre application fonctionne juste après la mise en production, c’est bien. S’assurer que cette dernière ne nous lâchera pas au milieu de la nuit, c’est encore mieux.

Pour cela, une solution : le monitoring.

Dans notre cas, le monitoring consiste à envoyer une requête (ou une suite de requêtes) toutes les X minutes/heures et à s’assurer que l’application retourne bien le résultat attendu.

Pour cela, nous avions déjà un outil en place : New Relic.

Afin de vérifier qu’une application web est toujours « en vie », New Relic propose quatre options :

Jusqu’à présent, seules les deux premières options étaient utilisées. On ne vérifiait jamais en profondeur que toute l’application fonctionnait comme il faut.

Il a été décidé de remédier à cela est c’est ainsi que j’ai créé des script web pour New Relic en utilisant l’outil Katalon.

Katalon est un outil permettant d’enregistrer les actions effectuées dans son navigateur web afin de pouvoir les rejouer ultérieurement. Cet outil est donc (théoriquement) très pratique lorsque l’on doit automatiser des tests web.

Je n’irai pas par quatre chemins, Katalon est excessivement difficile d’utilisation. Si vous avez le choix, je vous déconseille l’usage de cet outil. Vous perdrez moins de temps à écrire directement les scripts à la main (plutôt que d’utiliser l’interface de Katalon qui permet de convertir vos tests en script New Relic). C’est d’ailleurs ce que j’ai fini par faire en me passant complètement de l’utilisation de Katalon.

Utiliser New Relic pour monitorer nos applications de façon plus pointue était une solution que nous avons pu mettre en place rapidement. Toutefois, cela nécessitait de réécrire de nouveaux tests en plus de ceux utilisant le langage Cucumber lié à l’outil Selenium que nous avions déjà. Ce n’était donc pas une solution optimale.

En parallèle de cela, nous avions décidé de changer la façon dont nous livrions nos projets et de remplacer l’outil de versionnage Github et Jenkins (outil permettant de déployer nos projets en production) par Gitlab CI (et docker).

Gitlab CI combine les fonctionnalités de Github et Jenkins. Il permet de faire beaucoup de choses et il est notamment possible de lui demander d’effectuer une suite de tâche à la demande ou toutes les X heures.

Comme Gitlab peut utiliser docker, il n’y a pas de réelle contrainte sur le langage que nous souhaitons utiliser. Ainsi, Gitlab CI était tout à fait à même d’exécuter les tests Cucumber + Selenium déjà existants.

A l’aide d’un « schedules » (planning) on va indiquer tous les "combien" nous souhaitons que les tests se lancent (une fois par jour, une fois par semaine, une fois par mois, etc…). Cette suite de tests étant plus longue à s’exécuter que ce qu’il y a sur New Relic, on se contentera de jouer ces tests une fois par jours, tous les jours.

En outre, cette suite de tests sera également lancée automatiquement après chaque mise en production (au lieu d’avoir à les lancer à la main). Cela permet :

Avoir des tests automatiques, c’est bien, mais c’est encore mieux s’il y a plusieurs personnes capables de les lancer et d’en interpréter (au moins grossièrement) le résultat.

Ainsi, automatiser les tests en eux-mêmes ne suffit pas. Il faut également simplifier au maximum la façon de lancer ces tests et rendre les résultats aussi clairs que possible.

Avant de passer à gitlab CI/CD, il était nécessaire de télécharger puis d’installer tout un tas de choses (maven, java, web driver) afin de pouvoir lancer les tests. C’était long, fastidieux et franchement pénible. En outre, il fallait répéter l’opération pour chaque ordinateur.

Désormais, il n’y a plus rien à installer. Il suffit de se rendre sur le site web de gitlab et de cliquer sur le bouton adéquate. Un mail vous sera envoyé si les tests échouent. En outre, le résultat (positif ou négatif) sera affiché sur l’interface web de gitlab.

Ainsi, nous constatons qu’il est désormais bien plus facile d’exécuter les tests. Mais qu’en est-il de l’interprétation des résultats ?

Jusqu’à présent, les résultats des tests étaient affichés sous la forme d’un simple « success » ou « fail » et il fallait fouiller dans les logs pour savoir exactement quels étaient les tests qui avaient échoués et à quelle étape.

On pourrait penser que simplement savoir qu’un test a échoué est suffisant. Ce n’est pas le cas. En matière de tests fonctionnel via une interface graphique, il peut y avoir de très nombreuses raisons pour lesquels un test échoue. Or, il est primordial de savoir si cela est dû à un bug bloquant ou non bloquant ou s’il s’agit simplement d’un bug dans le test lui-même (et non dans l’application testée).

Désormais, nous utilisons Saucelabs.  

Saucelabs est une plateforme cloud permettant de tester ses applications web et mobile. En effet, Saucelabs propose tout une gamme d’OS et de navigateurs sur lesquels lancer ses tests. Ainsi, pas besoin de posséder l’OS/navigateur que nous souhaitons tester. Il suffit d’envoyer ces tests à Saucelabs (via notre pipeline gitlab par exemple) qui se chargera de les exécuter sur la machine voulue.

L’un des gros avantages de Saucelabs, c’est qu’il permet de voir une vidéo replay de l’exécution des tests. Ainsi, il est possible de voir ce qu’il s’est passé exactement tout au long de l’exécution de vos tests. Il devient ainsi beaucoup plus facile de comprendre l’origine du problème que si nous devions nous contenter de lire un fichier de logs.

En outre, l’interface graphique de Saucelabs nous donne un « résumé » de nos tests où l’on voit, pour chaque test, si le test a échoué ou réussi ainsi que le temps qu’il a mis à s’exécuter.

Toutefois, le système est encore perfectible. C’est pourquoi il est important de communiquer avec les Product Owners. Cela nous permet de mieux comprendre leur besoin et d’affiner les informations retournées pour qu’elles soient le plus pertinentes possible.