Vous préférez parler à une vraie personne ? Notre centre d’appel du Mans est là pour ça
09 77 40 66 66
(prix d’un appel local, même si vous habitez loin du Mans)

La qualité chez ekWateur, Suite…

Dans notre article précédent, nous vous parlions de comment s’assurer de la bonne qualité d’une application avant même qu’elle ne soit visible et utilisable par les clients.

10 mars 2020

Dans l’article d’aujourd’hui, nous allons voir comment s’assurer de la qualité d’une application tout au long de son cycle de vie, et notamment une fois que l’application est en production (et donc visible et utilisable pour tous les utilisateurs). Nous verrons également comment faire en sorte de rendre les équipes plus indépendantes vis-à-vis des tests.

C’est moi, Ælis Nolwenn, responsable qualité chez ekWateur, qui vous raconte.

Note avant d’aller plus loin : Nous n’avons pas été rémunéré pour parler des applications citées dans cet article.

Un électrocardiogramme affichant un cœur

S’assurer de la qualité de nos applications en tout temps

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 :

-        Un ping : on envoie une requête à une URL spécifique et on vérifie que la réponse contient le mot-clé que l’on souhaite.

-        Un chargement de page web : on entre une URL, on vérifie que la page charge bien et on s’assure que ladite page contient le mot clé que l’on souhaite.

-        Un script web : on envoie une suite de requêtes à un site web et on vérifie toutes les conditions que l’on souhaite.

-        Un script API web : on envoie une suite de requêtes à une API web et on vérifie toutes les conditions que l’on souhaite.

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.

 

offre d'énergie renouvelable

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 :

  1. D’éviter d’oublier de les lancer (très peu probable, mais on ne sait jamais).
  2. D’éviter d’avoir des soucis tels que « il n’y a que Bidule qui sait lancer les tests, mais Bidule n’est pas là ».

Rendre les Product Owners et les Développeur·euse·s plus autonomes

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.