On a construit une plateforme de test mobile.

Alors oui je vous vois déjà venir avec vos questions… « Mais à l’heure du cloud, en 2019, comment on peut encore faire du bricolage face aux pléthores de solution en ligne ? » « Pourquoi griller du gaz à retravailler des solutions existantes clés en mains ? » « Vous allez réinventer la roue non ? » …

Que nenni cher lecteur, et nous allons vous éclairer sur ce choix assumé.

Chez Leroy Merlin France, l’équipe Qualité s’emploie à fournir aux équipes un ensemble d’outils et de services pour améliorer et gérer la qualité de leurs livrables.

Dans le cadre de cet article, nous allons nous concentrer sur la partie test mobile. Aujourd’hui, le trafic mobile représente 50% de notre trafic sur notre site internet. En revanche, la partie testing de notre site internet était loin de représenter cette répartition. La recette sur mobile était essentiellement manuelle et incomplète : manque de couverture fonctionnelle, de modèles de téléphones, de versions d’OS, etc.

Nous avons une solution de test automatisé sur desktop, qui tourne quotidiennement et à chaque déploiement, tout environnement confondu. Cet outil nous assure une non-régression lors des livraisons. Mais alors, comment transposer cette solution à l’identique sur le mobile ?

Nos expérimentations

De quoi avons-nous besoin ?

Soyons clair, des critères on en avait beaucoup… mais globalement s’il fallait retenir les principaux, nous citerions :

• Une ferme de téléphones bien diversifiée : Android et iOS c’est indispensable ! Idéalement plusieurs modèles et possédant des versions d’OS différentes pour permettre une couverture la plus complète possible (bon, en réalité pour identifier ce besoin, nous avons simplement consulté notre analytics pour identifier les smartphones et versions d’OS cibles de nos habitants).
• Compatible avec notre outil de non-régression : Cette compatibilité nous assure de capitaliser sur un process bien ancré de notre quotidien. Pour info, pour assurer la non-régression, nous utilisons Cerberus (cerberus-testing.org), un outil open source qui permet d’exécuter nos tests automatisés sur des serveurs Selenium et Appium.
• Le temps d’exécution d’une campagne de tests : L’exécution de ces campagnes de tests s’intègre dans nos process de livraison, nous avons donc une exigence forte sur cette durée.

Les principaux besoins identifiés, il est temps de faire un tour sur les possibilités de combler nos attentes.

Ne pas réinventer la roue !

Nous avons commencé par sonder le marché : existe-t-il des services mettant à disposition une ferme de téléphones ? Peut-on bénéficier de retours d’expériences d’expérimentations similaires ?

De très nombreux outils proposent de louer les services d’une ferme de téléphones : que ce soit pour réaliser du test manuel à distance, du test d’application mobile ou du test web mobile (sur un navigateur). Ces outils présentent tous un très large choix de téléphones, qu’ils soient dans un cloud public, c’est-à-dire disponibles par tous les utilisateurs du service, ou privé, c’est-à-dire qu’ils vous sont réservés et que personne d’autre ne peut en disposer.

Nous avons expérimenté certains outils du marché, ils proposent souvent un compte gratuit pour plusieurs jours ou plusieurs minutes d’utilisation. Nous avons choisi de tester les solutions suivantes : Amazon Web Services Device Farm, Firebase Test Lab, Visual Studio App Center, Kobiton, Perfecto, Sauce Labs et Browserstack.

Ce que nous en avons pensé ?

Parmi les outils cités ci-dessus, nous avons éliminé Amazon Web Services Device Farm, Firebase Test Lab, Visual Studio App Center, Perfecto et Sauce Labs car ils ne répondaient pas à nos principaux critères.

Nous avons poursuivi avec Kobiton et Browserstack en prenant contact avec la partie commerciale de chacun d’entre eux. En obtenant des comptes d’essai, des tests à grande échelle ont pu être réalisés : une campagne de tests sur plusieurs téléphones dans un cloud privé.

Cela nous a permis d’en tirer des métriques comme le temps de mise à disposition d’un téléphone, le temps d’exécution d’un test, le temps total d’exécution d’une campagne de non-régression, etc.

Concrètement, nous avons trouvé Kobiton plus réactif face aux nouvelles versions des outils et OS utilisés par la ferme (Appium, iOS, Android). La solution propose également d’intégrer nos propres téléphones sur notre cloud privé.

Hors coût de maintenance, nous avons estimé le coût d’une plateforme mobile chez Kobiton à 60 000€ annuels, pour une plateforme composée de 20 téléphones sur un cloud privé (10 Android et 10 iOS).

En revanche nous avions constaté que les temps d’exécution des tests étaient beaucoup plus longs que lors de leurs exécutions sur un device physique chez nous.

Et si on se lançait ?

Partant de ce constat, la question d’une plateforme « homemade » a commencé à émerger dans l’équipe : nous avions les compétences pour réaliser une ferme de téléphones compatible à notre outil de test automatisé. Pourquoi ne pas tenter un POC ?

Notre challenger

Nous avons démarré un POC de plateforme de test mobile en empruntant les téléphones des membres de l’équipe. Nous avons mis en place des serveurs appium, branchés nos smartphones et en voiture Simone !

Ok, dans la réalité avec beaucoup d’huile de coude, nous avons procédé aux mêmes essais réalisés avec Kobiton.

Le match Kobiton Vs Plateforme Homemade.

Dans le coin gauche, Kobiton aligne 5 téléphones Android.

Dans le coin droit, la plateforme homemade peine à rassembler 3 smartphones. Mais regardez comme ils ont l’air fier et combatif !

Pour gagner, il faut exécuter une campagne de 22 tests le plus rapidement possible.

Fight… Le match est terrible, presque sanglant, ça sent la sueur et le processeur qui chauffe. Ils sont presque tous à terre, mais des têtes se relèvent et là… verdict :

• Kobiton : temps d’exécution : 22 minutes
• Plateforme Homemade : 7 minutes !!

A peine le temps d’un café, le match était plié, la solution maison semble beaucoup plus véloce.

Replaçons ces mesures dans le contexte : nous souhaitons mettre à disposition cette plateforme aux équipes pour faciliter la recette, et permettre d’exécuter des tests de non régression dans le cadre de déploiement continue, nous devons privilégier la rapidité d’exécution.

En tablant sur 20 smartphones (10 Android et 10 iOS) :

Kobiton :

Budget : 60 000€ annuel (hors coût de maintenance).

Temps d’exécution de 22 tests sur 10 smartphones : 13 minutes environ.

Plateforme homemade :

Budget : 30 000€ la première année (avec achat de matériel + provision de 3 jours de maintenance par mois) puis 15 000€ annuel (3 jours de maintenance + marge pour remplacement de téléphone)

Temps d’exécution de 22 tests sur 10 smartphones : 3 minutes environ.

Les données sont parlantes et nous ont convaincues de monter notre propre plateforme de test mobile !

Notre cible

En synthèse des éléments cités plus haut dans l’article, notre cible est simple : 10 Android et 10 iPhones représentatifs des devices utilisés par nos habitants. Dans un premier temps, nous choisissons également de lancer nos tests Android sur Chrome et nos tests iOS sur Safari.

Notre solution

On entre enfin dans le vif du sujet ! C’est bien connu, chez Leroy Merlin on aime le DIY, et c’est dans cet état d’esprit que nous avons conçu notre plateforme de test mobile.

Côté Hard

Nous avons conçu un modèle de support pour 10 smartphones répondant aux contraintes suivantes :

• Accueillir n’importe quel smartphone.
• Ne pas pouvoir prendre les smartphones du support (on a déjà testé les mobiles boomerangs, ça n’existe pas et ça ne revient pas tout seul…).
• Laisser les devices accessibles pour permettre de la recette manuelle.
• Garder accessible l’ensemble de leurs fonctionnalités et leurs boutons.
• Un support simple, facile à construire.

Dans notre tête, ça ressemblait à ça :

On a fait notre liste de course et direction notre magasin de bricolage préféré ;)

La partie la plus fun commence : « let’s DIY »

TADA !!

Maintenant que nous avons les plus beaux des supports, passons à la partie logicielle de notre plateforme.

Remarque : pour piloter les devices de chaque support, nous utilisons des Macs. Ce choix est guidé par la contrainte d’utiliser du Apple pour piloter du Apple. Pour la partie Android, nous avons décidé d’uniformiser les ressources des plateformes afin de ne pas avoir à maintenir 2 stacks techniques différentes.

Côté Soft

Chaque OS nécessitant des outils spécifiques, nous avons mis en place deux stacks techniques distinctes pour Andoid et iOS.

Côté Android, nous utilisons bien entendu l’Android SDK avec ses platform-tools, et notamment Android Debug Bridge. ADB est un outil essentiel dans la plateforme puisque c’est lui qui permet d’établir la connexion avec le téléphone et de le contrôler. Le framework de test utilisé pour Android est UiAutomator, il permet d’interagir avec des éléments web (cliquer, taper, scroller, etc).

Côté iOS, nous utilisons XCode ainsi que le serveur Web Driver Agent (WDA), produit par Facebook. Il est automatiquement installé avec Appium et est utilisé pour le contrôle des iPhones. Il fonctionne de pair avec un framework de test, XCUITest est celui utilisé pour iOS.

Que ce soit pour Android ou pour iOS, nous avons besoin de serveurs Appium. Chaque serveur Appium est configuré pour cibler un téléphone et occupe un port qui lui est propre.

Dans notre outil de tests automatisés, nous avons configuré un « robot » pour Android et un second pour iOS (ensemble d’informations qui permettent de cibler les devices pour les tests). Pour chaque robot, nous précisons quel est le framework de test utilisé : UiAutomator ou XCUITest.

Lorsqu’un test est lancé sur un robot, l’outil de tests automatisés envoie les ordres (c’est-à-dire les actions qui constituent un scénario de test) à un nœud Appium disponible. Si aucun nœud n’est disponible, le test est mis en attente jusqu’à être exécuté par le premier nœud de nouveau disponible.

Concrètement, ce que vous verrez sur le téléphone : il se déverrouille, ouvre un navigateur Chrome ou Safari, se rend sur le site et joue les actions du scénario (cliquer, taper du texte, contrôler le texte et les éléments visibles, etc.) puis ferme le navigateur et renvoie le résultat d’exécution à notre outil de tests automatisés.

Bilan

Les plateformes de test mobile Android et iOS sont physiquement installées.

Elles sont bien évidemment utilisées pour du test automatisé, mais également pour de la recette manuelle. Nous avons étoffé nos plateformes de modes d’emploi simples et ludiques qui permettent à tout le monde de l’utiliser facilement, mais aussi de la redémarrer ou de la débloquer si besoin.

Afin de contenir le coût de maintenance, nous avons également poussé plus loin le côté autonome de la plateforme. Aujourd’hui, grâce à une prise connectée et une bonne dose de scripts :

• Elle démarre seule le matin (allumage des hubs USB + démarrage des serveurs Appium),
• Elle se monitore toutes les 10 minutes pour contrôler que l’ensemble des smartphones est bien connecté et reconnu (elle nous envoie une alerte sur Slack dans le cas contraire)
• Elle s’éteint toute seule le soir (arrêt des serveurs Appium, et arrêt de la prise connectée)

De cette manière nous préservons la durée de vie de la batterie de nos smartphones. Si besoin, un script de redémarrage complet est à disposition pour rafraichir nos devices.

Notre expérience personnelle a mis en évidence qu’il était plutôt simple de mettre en place une stack stable et fonctionnelle sur Android, mais qu’il était beaucoup plus compliqué d’obtenir l’équivalent pour iOS. Quoiqu’il en soit, nous sommes plutôt fiers de dire que son utilisation fait partie de nos « réflexes » qualité : des campagnes de tests sont lancées quotidiennement et à chaque déploiement par les équipes, ce qui est une première belle victoire.

Notre deuxième victoire va sûrement vous intéresser un peu plus. Nous avons partagé en open source l’ensemble des ressources nécessaires pour construire, installer et configurer une plateforme de test mobile.

N’attendez plus, construisez la vôtre et lancez-vous dans l’expérience du test mobile en vous rendant sur https://mobile-platform.leroymerlin.fr