Automatiser les tests mobiles : Appium, Espresso, XCUITest
Le gain du jour : savoir quand automatiser (et quand ne pas le faire), et connaître les trois outils de référence pour l’automatisation de tests mobiles.
Le critère décisif : la fréquence, pas la difficulté
L’erreur classique est de choisir quoi automatiser en fonction de la difficulté technique. Le bon critère est différent : un scénario mérite d’être automatisé s’il est rejoué souvent — à chaque build, à chaque release, en test de régression. Un scénario testé une seule fois (une nouvelle fonctionnalité exploratoire, par exemple) ne justifie presque jamais l’investissement d’automatisation.
Automatiser un test coûte du temps à écrire et à maintenir (un test casse souvent après un changement d’interface, même sans bug réel). Ce coût n’est rentabilisé que si le test est rejoué suffisamment de fois. Un parcours critique (connexion, paiement) rejoué à chaque build, plusieurs fois par jour, rentabilise vite l’investissement. Un écran secondaire modifié une fois tous les six mois, presque jamais.
Les trois outils de référence
Espresso — le framework officiel de Google pour Android. Il tourne dans le même processus que l’app testée, ce qui le rend rapide et fiable, mais limité à Android uniquement.
XCUITest — le framework officiel d’Apple pour iOS, intégré à Xcode. Même logique qu’Espresso côté Apple : rapide, fiable, mais iOS uniquement.
Appium — un framework multiplateforme (Android et iOS avec la même API, inspirée de Selenium WebDriver côté web) qui pilote l’app depuis l’extérieur via un protocole standard. Plus lent qu’Espresso ou XCUITest, mais permet de mutualiser une partie du code de test entre les deux plateformes — un choix fréquent quand une équipe QA doit couvrir Android et iOS avec des ressources limitées.
Anatomie d’un test automatisé, en pseudo-code
Un test automatisé reprend directement la structure du cas de test manuel vu en leçon 7 — les mêmes étapes et le même résultat attendu, traduits en instructions exécutables par la machine :
test "Connexion avec identifiants valides après déconnexion" :
lancer_app()
taper(champ_email).saisir("test@exemple.com")
taper(champ_mot_de_passe).saisir("motdepasse_valide")
taper(bouton_se_connecter)
attendre(ecran_accueil, timeout=3s)
verifier(ecran_accueil.est_affiche == true)
verifier(menu_profil.nom_affiche == "Test User")Quand l’équipe travaille en BDD, ce même test est piloté par le scénario Gherkin de
la leçon 8 : le fichier .feature
reste lisible par le métier, et ce pseudo-code devient la step definition qui
l’exécute réellement via Appium, Espresso ou XCUITest.
Ce test, une fois écrit, tourne à chaque build sans intervention humaine — souvent déclenché automatiquement par une pipeline d’intégration continue (CI), avec les résultats remontés directement au tracker de bugs en cas d’échec.
Les tests visuels et le cloud de devices
Automatiser sur un seul appareil ne couvre pas la fragmentation vue en leçon 3. Des services comme BrowserStack App Automate ou Firebase Test Lab exécutent la même suite de tests automatisés sur des dizaines d’appareils réels ou virtuels en parallèle (différentes tailles d’écran, versions d’OS), sans que l’équipe ait besoin de posséder physiquement chaque appareil.
Ce que l’automatisation ne remplace pas
L’automatisation excelle en régression scriptée, mais reste aveugle à tout ce qui n’a pas été explicitement prévu dans le script : une incohérence visuelle subtile, une confusion dans le parcours utilisateur, un texte mal traduit. C’est pourquoi la pyramide des tests (leçon 4) et le test exploratoire (leçon 6) restent des piliers même dans une équipe fortement automatisée — l’automatisation change combien de temps humain reste disponible pour l’exploratoire, pas le besoin de test manuel lui-même.
Vérifie ta compréhension
Une équipe QA doit couvrir à la fois Android et iOS avec une seule petite équipe. Quel outil privilégier pour mutualiser le code de test ?
Quel est le principal critère pour décider si un scénario de test mérite d'être automatisé ?
À toi de jouer
Reprends le cas de test que tu as rédigé en leçon 7 et traduis-le en pseudo-code de test automatisé, sur le modèle de cette leçon.
Pour une app que tu connais, identifie trois parcours qui, selon toi, mériteraient d’être automatisés en priorité, et justifie par leur fréquence de réexécution probable.
🗂 Fiche de référence associée : Glossaire QA mobile — antisèche.