Lecture 19 minutes

Préambule

Il y a quelques jours, j'ai participé à une réunion avec l'un de nos clients qui souhaitait "savoir s’il était possible de commander sur son site à un instant T". Vous allez vous dire « heureusement que l’on peut commander sur un site E-commerce », malheureusement les choses ne sont pas aussi simples et nous ne sommes jamais à l’abri d’un bug.

Pour apporter une réponse à cette question – qui est cruciale pour un E-commerçant - l’enjeu va être de mettre en place des tests automatisés, permettant d’identifier des problèmes critiques tel que
l’impossibilité de mener à bien une commande sur un site marchand.

La mise en place de ces tests permettent ainsi d’apporter une réponse fiable à nos clients et ce de manière régulière (tous les jours, ou plus ponctuellement lors de chaque livraison). Une autre façon de le dire est qu’un système va réaliser une commande et nous confirmer ou non qu’elle a bien pu être passée.

De manière plus globale, les tests automatisés permettent de s’assurer que le code mis en place sur une plateforme permet effectivement d’atteindre l’objectif donné. Plus particulièrement dans ce cas, il s’agit de tests fonctionnels : nous testerons donc que notre code atteint l’objectif fonctionnel donné (afficher une information, possibilité d’ajouter un produit au panier, prix d’un produit, etc).

Ce sujet est très vaste et mérite qu’on s’y attarde, afin de répondre à plusieurs questions :

• Quel outil utiliser ?
• Ai-je besoin d’une solution Saas ? Hébergée ?
• Ai-je besoin d’alertes ?
• Quand ces tests doivent-ils être réalisés ?
• De quoi l’intégrateur a-t-il besoin ?
• Etc.

C'est ce à quoi je vais tenter de répondre dans ce "petit" article.

 

Le besoin

Il est nécessaire d’avoir un certain recul sur l’E-commerce, et plus largement sur les tests automatisés afin d’isoler le besoin réel de notre client.

En effet, on le comprend aisément : il souhaite "pouvoir s'assurer qu'un utilisateur qui vient sur son site peut effectuer une commande en partant de la page d'accueil, jusqu'au système de paiement".

Et c'est déjà une expression un peu plus complète (fruit de mon interprétation certes, mais qui répondra vraisemblablement au besoin du client).

Pourquoi j'insiste là-dessus me direz-vous ? Eh bien parce qu'il existe des systèmes qui vérifieront qu'on peut réaliser une commande sur le site, qui le valideront alors qu'en fait... ce n'est pas possible !

 

Les navigateurs

Pour comprendre comment ça fonctionne, parlons déjà des navigateurs traditionnels (votre Chrome ou votre Firefox (Je ne cite pas « Internet Explorer » : pas de vulgarité ici s'il vous plait)).

Voici (grossièrement) ce qui se passe quand on utilise un navigateur traditionnel :

1. On demande l'url

2. Le navigateur récupère le code HTML du site

3. Le navigateur récupère tous les fichiers associés au site (images, javascript, etc)

4. Le navigateur interprète tout cela, et le moteur de rendu nous l'affiche.

5. Le JS peut modifier en live le contenu (par exemple sur mouvement de la souris)

 

Certains systèmes automatisés se contentent des étapes 1 et 2. Ils n'interprètent pas ce qui se passe après, pour un utilisateur réel ! C’était par exemple le cas du robot Google il y a encore quelques années. On affirmait alors : "Attention au JS, Google ne l’interprète pas".

Supposons maintenant que le JS modifie le contenu de la page en étape 5, en supprimant le bouton d'ajout au panier (oui, c’est une fonction stupide : On imagine juste !). Un navigateur ne reproduisant que 1 et 2 pour chaque page serait donc en mesure de commander le produit, en faisant se succéder des pages avec les bons paramètres, alors qu'un utilisateur lui, ne serait pas en mesure d'effectuer cette opération.

C'est un peu la même rengaine que ce bon vieux débogage sur Internet Explorer 5 (les anciens me comprendront) : Selon le navigateur que l'on utilise, le rendu n'est pas le même. Et donc, selon le navigateur que notre système de test utilise, le résultat ne sera pas le même.

Retours au besoin

Je reviens donc à mon besoin qu'il va falloir encore préciser.

Ce que nous savons :

• Il faut pouvoir simuler le comportement d'un utilisateur pour un scénario donné.

 

Ce que nous ignorons encore :

• A quelle fréquence souhaite-t-on recevoir des alertes ?
• Quelle exhaustivité souhaite-t-on (chrome, firefox, IE, mobile, etc) ?
• Quel est le budget ?

 

Je ne vais pas me simplifier les choses, partons du principe que :

• ... nous souhaitons lancer le scénario plusieurs fois par jours.
• ... nous souhaitons le plus d'exhaustivité possible (firefox, IE, mobile, firefox, etc).
• ... nous disposons d'un budget très limité.

 

Comparatif de quelques solutions

Selenium Hébergé

Prix : $$$

Description : Selenium est une application capable de lancer et piloter des navigateurs, par l'intermédiaire de scripts rédigés par des techniciens dans différents langages (Java, PHP, etc). Il propose de très nombreux adaptateurs et est un des leaders du marché.

Sa mise en œuvre nécessite un effort de déploiement qui peut être relativement lourd. On ne parle donc pas ici de coût de licence (contrairement aux autres offres décrites ci-dessous), mais de coût de déploiement.

C'est cette solution que nous utilisons pour lancer nos tests fonctionnels après déploiement.

Cela nous permet de nous assurer que les scénarios de base de nos sites fonctionnent.

En revanche, il s’agit là d’un lancement piloté par nos déploiements. De plus, il n’existe pas d’interface dédiée permettant de piloter spécifiquement ces tests.

La mise en place d’une infrastructure permettant de lancer régulièrement ces tests représente un coût non négligeable (plusieurs jours de travail et de maintenance par la suite). De plus, il faudrait prévoir une interface de gestion permettant de piloter l'application de manière ergonomique, ce qui représenterait également un coût colossal… alors que ce genre de système existe déjà.

Enfin, la rédaction de script Selenium peut rapidement s’avérer complexe (et donc présenter là aussi un coût important). S’ils sont capables de répondre à quasiment tous les cas de figure, ils peuvent rapidement présenter une charge trop importante pour le besoin initial.

J’appellerai cela : "Prendre un bazooka pour tuer une mouche".

Pour faire simple, Selenium n'est qu'un outil, au même titre que GIT par exemple.

ATTENTION : Selenium n’est pas toujours surdimensionné et peut (dans de nombreux cas) être la réponse au besoin. Mais ce n’était pas le cas ici.

Nombre de tests : Illimités (enfin si, par la machine qui héberge)

Nombre d'utilisateurs : Illimités (enfin si, par la machine qui héberge)

 

BrowserStack (service "automation")

Prix : 129$ par mois

Description : Il permet d'écrire des scripts Selenium. Si Selenium est comparable à Git, BrowserStack serait une sorte de Github pour Selenium.

Ce service ne nous convient pas (dans ce contexte). En effet, s'il faut écrire des tests Selenium, autant le faire sur notre infrastructure, qui le supporte.

L’avantage de ce service pourrait être le fait de les lancer régulièrement, mais dans ce cas, il faudrait déporter tous les outils que notre Selenium utilise sur BrowserStack. La migration ne nous semble pas être une très bonne idée.

De plus, cela implique de mobiliser des personnes capables de créer et gérer des scripts Selenium. Ces profils sont relativement rares et là encore, présentent un coût important.

Notons tout de même que ce service peut être utilisé pour réaliser des tests "manuels" sur de nombreux navigateurs et périphériques. Nous l'utilisons à ce titre chez Synolia.

Nombre de tests : 1 test en parallèle possible

Nombre d'utilisateurs : 1 (attention : dans ce cadre, votre prestataire n'est pas supposé pouvoir intervenir sur ce compte car c'est celui du client)

 

Changement de point de vue

A partir de là, il me paraissait évident qu'il ne fallait pas partir sur une solution technico technique. Il ne fallait pas penser "outillage" mais "fonctionnel".

Ce que je voulais, c'était pouvoir créer simplement des scénarios et les rejouer. Que ce soit "Selenium" ou une autre application ne m'intéressait pas.

Comme aurait dit mon client : "Moi je veux juste savoir si on peut commander c'est simple."

En conséquence, je décidais d'écarter "Saucelabs", "Lambdatest" et "Heliumhq" ressemblants de trop prêt à BrowserStack (des sortes d'hébergements Selenium en somme).

Le client m'avait soufflé dans l'oreille qu'il avait travaillé avec "Ghost Inspector" à une époque. J'avais déjà vu ce genre de solutions avant : une interface très simple permettant de créer des scénarios via des outils graphiques. Ce genre de service pouvait totalement convenir en effet.

Je décidais donc d'en étudier trois : Tests Anywhere, Mabl, et enfin Ghost Inspector.

 

TestAnywhere(.co)

Prix : 29.99 par mois

Description : TestAnywhere utilise une extension Chrome pour fonctionner et... c'est tout ce que je peux vous en dire. En effet, à l'heure où j'écris ces lignes, l'extension en question m'indique "no internet connection" (je l’ai testé sur 3 réseaux différents sans succès). Cela a été un peu rédhibitoire, me disant que si dès le départ, ça ne fonctionnait pas, j'aurai bien du mal à le proposer à des clients.

 

Mabl (offre Growth)

Prix : ???

Description : Dans un premier temps, le fait que le prix ne soit pas affiché sur le site m'a déplu, mais étant donné que TestAnywhere ne voulait pas marcher, il me fallait des points de comparaison !

Donc, je me lance dans Mabl : je créé un compte, et après quelques minutes, je comprends qu'un "test" chez eux est un périple ("journey"), et qu'il est possible d'enregistrer des "journeys" avec une petite extension Chrome.

Je télécharge donc l'extension Chrome, me positionne sur mon site préféré, et je commence à enregistrer.

Chose très sympa : Je vois mon test se construire au fur et à mesure que j'avance.

 

Une fois terminé, j'ai accès à mon test dans l'interface mabl (ici "Test site Synolia").

 

 

 

Il m'est d'ailleurs possible de l'éditer : chose obligatoire car l'enregistreur n'a pas totalement fonctionné. Il n'a par exemple pas traité mes passages de souris sur les menus.

 

Enfin, j'ai la possibilité de créer des "plans" qui sont des jeux de "périples". Ce sont en fait les "plans" qui sont joués. Il est donc impératif d’avoir un plan contenant notre périple pour pouvoir jouer le test.

 

Voici d’ailleurs la vue détaillée des « plans en question ».

 

 

J'ai noté deux points rédhibitoires : en moins d'une heure de tests, j'ai rencontré 2 bugs. L'extension a complètement planté et lors de l'édition de mon "périple", les outils se comportaient de manière étrange. De plus, Mabl et son extension sont extrêmement lents.

Nombre de tests : 2000 par mois

Nombre maximum d'utilisateurs : ???

 

TestCraft

Prix : ?

Description : Ce système a l'air très prometteur. Il semble fournir une interface radicalement différente de Ghost Inspector et de Mabl, malheureusement, ils n'ont pas souhaité me fournir de compte d'essai, ni d'informations sur la politique tarifaire. Je suis actuellement dans l'attente d'une démo de leur part.

 

Ghost Inspector

Prix : 71$ / mois

Description : Ce service ressemble énormément à Mabl. Donc là aussi je créé un compte, et je télécharge la petite extension permettant d'enregistrer un scénario.

Et me voilà reparti sur mon site préféré, pour réaliser le même test que précédemment. Là par contre, je n'ai pas le test qui se construit au fur et à mesure.

 

Une fois terminé, Ghost Inspector me permet, comme Mabl, de visualiser mes tests.

 

Là aussi je peux l'éditer. C'est un tout petit peu moins "visuel" que Mabl, mais ça fonctionne. Ce que je remarque surtout, c’est qu’il faut être un peu plus « technique » car il faut savoir lire des sélecteurs CSS (en réalité, c’est la même chose sur Mabl dès que l’on souhaite un scénario un tout petit peu élaboré).

 

Et il m'est également possible de programmer ce test tous les X temps :

 

Ghost Inspector me propose en plus une petite vidéo de mon test : Ce qui est très pratique pour déterminer où est le problème lors de mes ajustements.

 

Concrètement, Ghost Inspector semble convenir parfaitement. C'est une sorte de Mabl sans bug ni lenteur, et avec des fonctionnalités en plus.

Nombre de tests : 10000 lancements par mois

Nombre maximum d'utilisateurs : 5

 

Ca répond au besoin ?

Notre besoin était donc :

• pouvoir simuler le comportement d'un utilisateur pour un scénario donné.
• pouvoir lancer le scénario régulièrement.
• pouvoir lancer le test sur chrome, firefox, internet explorer, safari ios et chrome android (j'ai précisé un peu par rapport à ci-dessus)

Le tout, avec un budget très limité.

Je compare ici Mabl et Ghost inspector qui sont les plus pertinents selon moi.

 

	Mabl (Plan « Growth)	Ghost Inspector (Plan Small)
Nombre d’utilisateurs	Non précisé	5
Nombre de tests par mois	2000	10000
Rétention de la donnée	3 mois	6 mois
Simuler le comportement d’un utilisateur	✓	✓
Pour lancer le scénario régulièrement	✓	✓
Prise en charge de chrome	✓	✓
Prise en charge de firefox	✓	✓
Prise en charge d’Internet Explorer	✓	✗
Prise en charge de Safari	✓	✗
Prise en charge de la vidéo	✗	✓
Prix	A discuter avec l'éditeur	71$ / mois
Complexité de mise en œuvre de tests	Moyenne (car pas de vidéo)	Simple

 

 

Si on fait abstraction des petits soucis de lenteurs et des bugs que j’ai rencontrés sur Mabl, les critères qui vont conditionner votre choix sont :

• Le budget
• Le nombre de tests par mois
• Le fait de souhaiter ou non tester sur Internet Explorer et Safari
• Et mes tests mobiles ?

 

Le Budget

Les prix sont détaillés dans le tableau. La mise en œuvre par votre intégrateur représentera sensiblement la même charge entre Mabl et Ghost Inspector.

 

Le nombre de tests par mois

Ce critère est très important car il peut vous faire basculer d’une tranche de prix à une autre.

Supposons les volumes suivants :

• Vous disposez de 5 sites.
• Sur chaque site vous souhaitez lancer 10 tests par session (je vous invite à réfléchir à 10 scénarios différents, vous verrez que ce n’est pas si facile).
• Vous souhaitez lancer deux sessions de tests par jour.
• Vous souhaitez lancer les tests à chaque livraison.
• Vous souhaitez lancer les tests sur Chrome et Firefox (2 navigateurs)
• Vous livrez votre site 3 fois par semaines (c’est beaucoup trop mais c’est une autre histoire).
• On suppose un mois de 31 jours et 5 semaines (on prend large).

Nous obtenons donc : (((5 sites x 10 tests x 2 sessions par jour x 31 jours) + (3 livraisons x 5 semaines x 10 tests)) x 2 navigateurs) = 6500 tests.

Dans ce cas, vous devrez prendre le plan le plus élevé chez Mabl ou plusieurs plans « Growth »

 

Si vos volumes sont plus "raisonnables" :

• Vous disposez de 1 site.
• Sur chaque site vous souhaitez lancer 5 tests par session
• Vous souhaitez lancer une session de tests par jour.
• Vous souhaitez lancer les tests à chaque livraison.
• Vous souhaitez lancer les tests sur Chrome, Firefox, Internet Explorer et Safari (4 navigateurs)
• Vous livrez votre site 1 fois par semaines.
• On suppose un mois de 31 jours et 5 semaines (on prend toujours large).

Nous obtenons donc : (((1 site x 5 tests x 1 session par jour x 31 jours) + (1 livraison x 5 semaines x 5 tests)) x 4 navigateurs) = 720 tests.

Bref, tout dépend de votre volumétrie !

 

Tester sur Internet Explorer et Safari

C’est une excellente question à se poser. En effet, Safari étant basé sur Webkit (le même moteur que Chrome - Ok, ce n'est plus tout à fait vrai, mais considérons que c'est acceptable) et Internet Explorer étant aujourd’hui (relativement) à jour sur les conventions, on peut estimer qu’un test sur Firefox et Chrome pourraient suffire. Je dis bien « on peut » estimer car nous ne sommes pas à l’abri d’un bug qui n’affecterait qu’un de ces navigateur.

Il s’agit là d’une (petite) prise de risque et tout dépendra de votre volonté de sécuriser ou non cette notion. Pour ceux qui ne connaîtraient pas, je vous invite à vous renseigner sur « le principe de Pareto » (aussi appelé principe des 80-20) avant de déterminer si oui ou non cette prise de risque est acceptable.

 

Et le mobile dans tout ça ?

Vous l’aurez remarqué, ces solutions ne proposent rien concernant le mobile. Pour faire simple, les tests mobiles nécessitent des outils bien plus complexes à mettre en œuvre.

Souvent, ils nécessitent une montée en compétence présentant un coût important et parfois même des infrastructures (hébergements) complexes.

De plus, les outils présentés fournissent tout de même la possibilité de choisir la résolution de l'écran. Ainsi, si ce n'est pas le "vrai" navigateur mobile qui est testé, il est tout de même possible de tester sa résolution.

Là encore, le choix de sécuriser ou non cette notion vous revient, sachant qu’une fois chrome et safari desktop testés dans la résolution des mobiles, on peut estimer que « le gros » des tests est couvert.

 

Et la mise en œuvre ?

Reste la question de la mise en œuvre de notre test. En effet, si nous commençons à avoir un besoin relativement précis, il va falloir maintenant s'assurer que notre test se lancera dans un environnement stable.

Client : "Bah j'espère bien qu'il est stable mon site."

Moi : "Oui, il l'est, mais la donnée elle ne l'est pas : Un produit peut être en stock ou ... hors stock par exemple."

Et cela pose un gros souci pour notre test. Je rappelle l'énoncé :

"pouvoir s'assurer qu'un utilisateur qui vient sur son site peut effectuer une commande en partant de la page d'accueil, jusqu'au système de paiement"

Hors si j'essaye de commander un produit hors stock, mon test ne pourra potentiellement pas le commander !

Il convient donc, selon le test à réaliser, de lister certains critères dont le client devra garantir la stabilité. Dans notre exemple il s'agit des éléments suivants :

• Une catégorie qui existera toujours.
• Un produit présent dans cette catégorie, qui aura toujours du stock et sera toujours en première position du listing en question.
• Le produit en question doit être directement "commandable" quand on arrive sur la page (taille et couleur pré-selectionnées par exemple)
• Un compte client existant.
• Une adresse de livraison et de facturation par défaut dans le carnet d'adresse du client en question.

 

Si l'un de ces éléments n'est plus stable, le test plantera logiquement.

Une fois la liste des critères stables fixée, la rédaction du test est relativement fluide : On enregistre avec le petit outil fourni par Ghost Inspector ou Mabl, et on modifie le script pour le "nettoyer".

Si sur la première étape, votre intégrateur n'est pas nécessaire, il y a fort à parier que sur la seconde vous serez probablement perdus. Votre intégrateur vous proposera d'ailleurs probablement de réaliser tout le travail (depuis l'enregistrement) pour avoir la main sur ce qu'il a fait.

Je vous conseille donc de ne pas essayer de créer des tests seuls, à moins d'avoir reçu une formation spécifique.

Enfin, il y a un autre critère à aborder que vous devez avoir en tête : lancer des tests provoquera la création de données de tests dans votre base de données. He oui, créer une commande a pour effet de … créer une commande ! Il faudra donc bien veiller à adapter votre SI ou vos process de façon à ignorer les données générées par les tests automatisés.

Par exemple, vous pourrez déterminer qu’une adresse ayant un format spécifique est considérée comme un test. Ainsi, toute commande réalisée par un client disposant d’un email à ce format sera ignorée par votre SI.

Sur ces aspects, si vous souhaitez l’automatiser, il faudra passer par votre intégrateur de façon à ce qu’il adapte les flux si nécessaire.

 

Conclusion(s)

Je vais essayer de résumer ma conclusion en quelques points :

• L’énoncé d'un test parait toujours simple, mais il entraîne de nombreuses questions qui conditionneront le choix d’outils. Vous devrez quoiqu’il en soit structurer votre démarche en exprimant le cas de test le plus précisément possible. "Un utilisateur créé un commande" ok, mais "un utilisateur" est une personne qui dispose d'un compte ou non ? Il créé une commande avec quel type de produit ? etc.
• Il vous faudra respecter et faire respecter une liste de prérequis pour que vos tests tournent correctement.
• Actuellement, parmi la liste des solutions testées, nous conseillons :
  • A minima : des tests Selenium pour les déploiements (mais ça c'est une autre histoire)
  • Dans l'idéal : des tests au déploiement (Selenium ou autre), et des tests Ghost Inspector ou Mabl réguliers, en plus de tests aux déploiements.
• Quoiqu'il en soit, les outils testés ne sont pas magiques et nécessitent l'intervention d'un technicien ou d'une personne formée.