Alternative à Appium et BrowserStack : automatiser sur un cloud d’appareils réels

Si vous automatisez quoi que ce soit sur mobile, vous avez probablement déjà eu recours à Appium et à BrowserStack. Ce sont les choix par défaut, et à juste titre. Mais dès l'instant où votre travail cesse d'être « lance ce test une fois puis démonte tout » pour devenir « garde cette session active et pilote-la chaque jour », les deux outils commencent à jouer contre vous. Un cloud d'appareils réels est la réponse à ce second problème : du vrai matériel que vous provisionnez depuis un tableau de bord, que vous gardez en fonctionnement continu, et que vous automatisez de la même façon, que vous testiez un build ou que vous exploitiez un compte.

Réponse courte : Appium est un framework d'automatisation open source, BrowserStack une grille de test multi-appareils partagée, et un cloud d'appareils réels un parc de téléphones physiques dédiés que vous pilotez à distance depuis un tableau de bord. Pour de l'automatisation continue sur du vrai matériel, plutôt que des exécutions de test ponctuelles sur un parc partagé, c'est le cloud d'appareils réels qui correspond.

Trois outils, trois métiers

Il vaut la peine d'être précis sur ce que chacun est réellement, car on les met dans le même sac sous l'étiquette « automatisation mobile » avant de les comparer sur le mauvais axe.

Appium est un framework. Il vous offre une API de type WebDriver pour scripter des taps, des swipes et des assertions sur des applications iOS et Android. Il est excellent, open source, et ce que l'industrie a de plus proche d'un standard. Mais Appium ne vous fournit pas d'appareils. Vous apportez votre propre matériel, ou vous le pointez vers le cloud de quelqu'un d'autre, et vous possédez toute la pile autour : le serveur Appium, les drivers, le provisionnement des appareils, l'instabilité. C'est une manière de piloter un appareil, pas un endroit où en obtenir un.

BrowserStack est une grille de test partagée. Il résout le problème « je n'ai pas 40 modèles d'appareils » en vous louant une tranche d'un vaste parc d'appareils réels le temps d'une session. Il est réellement solide sur ce pour quoi il a été conçu : la QA multi-navigateurs et multi-appareils, quand vous voulez confirmer qu'un build se comporte bien sur un iPhone 13, un Pixel 7 et un vieux Samsung sans avoir à acheter les trois. Vous obtenez l'appareil le temps du test, puis il retourne dans le parc pour le client suivant.

Un cloud d'appareils réels, au sens où nous l'entendons ici, est un parc de téléphones physiques dédiés qui vous sont assignés et laissés en fonctionnement. Vous en provisionnez un depuis un tableau de bord, vous le gardez actif d'une session à l'autre, et vous l'automatisez comme bon vous semble. L'appareil n'est pas partagé entre les exécutions de test et il n'est pas recyclé à la seconde où votre script se termine. Cette persistance est tout l'intérêt, et c'est précisément ce que les deux premiers ne sont pas conçus pour offrir.

Là où le modèle du cloud d'appareils réels l'emporte

Les différences apparaissent sur une matrice de capacités, pas sur une liste à cocher de fonctionnalités. Chaque outil est fort quelque part et tout simplement absent ailleurs.

Le schéma est constant. Appium vous donne un contrôle profond et scriptable mais aucun matériel et aucune persistance — vous fournissez les deux. BrowserStack vous donne une largeur d'appareils et une couverture multi-navigateurs propre, mais vous rend l'appareil après chaque session, si bien qu'un compte de longue durée ou un état préchauffé n'a nulle part où vivre. Un cloud d'appareils réels est le seul des trois où un vrai appareil physique, une session persistante et une automatisation complète cohabitent au même endroit.

Cette persistance compte plus qu'il n'y paraît. Une grille partagée est faite pour se réinitialiser entre les clients, ce qui est correct pour le test et faux pour tout ce qui a un état. Si vous avez besoin d'un appareil qui reste connecté, conserve ses données d'application, garde une session préchauffée et reste joignable demain à la même adresse, une location à la session ne peut pas vous l'offrir, peu importe le nombre de modèles proposés. Et parce que ce sont de vrais combinés plutôt que des instances virtualisées, l'empreinte est réelle — la même raison pour laquelle les appareils physiques surpassent les émulateurs pour la QA mobile.

Exécutions de test contre exploitation continue

La manière la plus nette de choisir est de se demander quelle forme a votre travail. Est-ce une salve — lancer une suite, obtenir un résultat, démonter — ou une opération permanente qui doit être là chaque jour ?

Si vous exécutez une suite de tests CI sur de nombreux modèles d'appareils, BrowserStack (ou une grille similaire) est un bon choix, et Appium est probablement déjà votre couche de scripting à l'intérieur. Aucune raison de bouger cela. Mais si l'« appareil » est quelque chose que vous exploitez plutôt que quelque chose contre quoi vous testez — un appareil réel qui doit rester en ligne, conserver un état et exécuter de l'automatisation en continu — le modèle de location vous combat et un cloud d'appareils réels dédiés ne le fait pas. C'est l'automatisation sur appareil réel comme capacité permanente, pas comme tâche planifiée.

Cette distinction explique pourquoi le test sur cloud d'appareils réels et l'exploitation d'appareils réels ne sont pas le même achat. Le test veut de la largeur et de la jetabilité. L'exploitation veut de la persistance et du matériel dédié. Tenter de mener la seconde sur un outillage conçu pour le premier, c'est là que les équipes finissent par se battre contre des reconnexions instables, des sessions perdues et des parcs qui réassignent leur appareil en pleine tâche.

Ce que vous possédez réellement avec chacun

Il y a aussi une question de propriété qui figure rarement dans la comparaison. Avec Appium, vous possédez tout, y compris les parties dont vous ne vouliez pas : le serveur, les drivers, les appareils physiques, les racks, les redémarrages. Ce contrôle est réel et parfois exactement ce qu'il faut. Mais c'est un coût opérationnel permanent, et pour la plupart des équipes ce n'est pas leur métier.

BrowserStack supprime ce fardeau et, en échange, vous ne possédez rien de durable — vous louez l'accès à un parc le temps d'une exécution. Un cloud d'appareils réels se situe entre les deux : le fournisseur possède et entretient le matériel physique, le garde alimenté et connecté, et vous remet un appareil dédié et persistant que vous pilotez à distance. Vous obtenez un contrôle d'automatisation façon Appium sans faire tourner un laboratoire d'appareils, et vous obtenez du vrai matériel sans le relouer au parc après chaque session. Vous pouvez voir comment le parc géré est structuré sur la présentation de la plateforme et comment il s'applique au travail sur appareils réels sur la page solutions QA & Testing.