Les offres d'automaticien de test mobile citent Appium avec Java ou TypeScript (WebdriverIO), souvent Playwright pour la partie web, Sauce Labs ou BrowserStack pour les terminaux, GitLab CI ou Jenkins, Jira et Xray, parfois Cucumber pour écrire les scénarios en Gherkin. Le poste est souvent mixte : la même personne automatise l'application web, l'API et l'application mobile.
Venus du web avec Selenium, beaucoup de candidats découvrent le mobile. Le langage WebDriver leur est familier, le reste ne l'est pas : capabilities, drivers UiAutomator2 et XCUITest, WebDriverAgent à signer pour un iPhone, contextes natif et WebView, gestes, autorisations du système, différences entre constructeurs Android. Appium est passé en version 3 en 2025, avec des drivers installés à part et un protocole W3C strict. Un CV qui parle de desiredCapabilities et de TouchAction décrit une expérience d'avant ces changements.
Demandez sur quels terminaux tournait la dernière suite, comment ils étaient choisis et combien de temps prenait une exécution. Le PDF contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Appium et l'écosystème du test mobile
Appium 3
Le serveur open source qui pilote des applications iOS et Android avec le protocole WebDriver, celui de Selenium. Depuis la version 2, les drivers s'installent à part, et la version 3 n'accepte plus que le protocole W3C. Les tests s'écrivent en Java, en TypeScript avec WebdriverIO, en Python ou en C#. Une version 4 est en bêta fin 2026.
UiAutomator2 (Android)
Le driver Appium pour Android. Il installe un petit serveur sur le téléphone ou l'émulateur et passe par adb, l'outil de Google pour piloter un appareil. Il donne accès aux identifiants des éléments, aux gestes et aux autorisations.
XCUITest et WebDriverAgent (iOS)
Le driver Appium pour iOS. Il installe sur l'iPhone ou le simulateur WebDriverAgent, qui s'appuie sur le framework de test d'Apple. Un Mac avec Xcode est obligatoire. Sur un vrai iPhone, WebDriverAgent doit être signé avec un compte Apple Developer, ce qui bloque souvent les débutants.
Espresso et XCUITest natifs
Les frameworks de test de Google et d'Apple, écrits en Kotlin ou en Swift dans le projet de l'application. Plus rapides et plus stables qu'Appium, ils sont souvent écrits par les développeurs. Un automaticien doit savoir les lire et dire quels tests leur reviennent.
Appium Inspector
L'outil graphique qui affiche l'arbre des éléments d'un écran et leurs attributs. Il sert à trouver un identifiant fiable et à tester un localisateur avant de l'écrire dans le code.
Fermes de terminaux
BrowserStack, Sauce Labs, AWS Device Farm ou LambdaTest louent l'accès à des centaines de vrais téléphones et à des émulateurs. On y envoie le build, puis les tests ouvrent leurs sessions à distance. Le coût dépend du nombre de sessions parallèles, et un tunnel permet d'atteindre un environnement de recette interne.
Émulateurs et simulateurs en CI
L'émulateur Android tourne sur un serveur Linux avec accélération matérielle. Le simulateur iOS exige une machine macOS. Ils servent aux vérifications rapides sur chaque merge request, avant la campagne sur vrais téléphones.
WebdriverIO, Java et Cucumber
Les deux clients les plus cités dans les offres sont WebdriverIO en TypeScript et le client Java d'Appium, souvent avec TestNG ou JUnit. Cucumber et Gherkin reviennent quand les scénarios sont écrits avec le métier. Choisissez le langage selon celui des tests existants de l'équipe.
L'automaticien mobile dépend des équipes de développement plus que ses collègues du web : il a besoin de builds de test, d'identifiants d'accessibilité posés dans le code, de liens profonds pour ouvrir un écran, et parfois d'un compte Apple Developer. Selon le poste, il automatise seulement l'application mobile ou aussi l'application web et l'API. Les applications écrites en Flutter ou en React Native se testent aussi avec Appium, avec des points d'attention sur les identifiants. Précisez dans l'offre si l'équipe dispose déjà d'une ferme de terminaux ou d'un parc de téléphones, et si des tests Espresso ou XCUITest existent.
Les compétences mobiles à vérifier en entretien
- Architecture Appium, drivers et capabilities
- Localisateurs et identifiants d'accessibilité
- Gestes, contextes WebView et liens profonds
- Autorisations, builds et signature iOS
- Couverture des terminaux et fermes
- Exécution en CI et diagnostic des échecs
Questions Appium sur iOS, Android et l'intégration continue
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Votre test Android trouve le bouton Commander par XPath et casse à chaque nouvelle version de l'application. Que proposez-vous ?
Une bonne réponseUn identifiant d'accessibilité convenu avec les développeurs : content-desc sur Android, accessibilityIdentifier sur iOS, testID en React Native, Semantics en Flutter. On le cible avec la stratégie accessibility id, la même sur les deux plateformes, ce qui permet de partager les objets page. À défaut, le resource-id sur Android, un prédicat ou une class chain sur iOS. Il sait que XPath est lent, surtout avec XCUITest.
Signal d'alerteUne XPath absolue copiée depuis Appium Inspector, ou un tap sur des coordonnées x et y qui change avec la taille de l'écran.
Question 2 · confirmé
L'application est hybride : le formulaire de paiement s'affiche dans une WebView. Comment l'automatisez-vous ?
Une bonne réponseIl liste les contextes disponibles, bascule du contexte NATIVE_APP vers le contexte WEBVIEW correspondant, puis utilise des sélecteurs web. La WebView doit être inspectable dans le build de test : setWebContentsDebuggingEnabled sur Android, isInspectable sur iOS depuis la version 16.4. Sur Android, Appium a besoin d'un Chromedriver compatible avec la version de la WebView, téléchargé automatiquement si le serveur l'autorise. Il revient en contexte natif pour les boîtes de dialogue du système.
Signal d'alerteTaper dans la WebView par coordonnées, ou ignorer la notion de contexte et chercher les champs web avec des sélecteurs natifs.
Question 3 · senior
Le métier demande de tester sur 40 modèles de téléphones. Comment décidez-vous sur quels terminaux tourne la suite ?
Une bonne réponseIl part des données d'usage réelles : modèles, versions d'OS et tailles d'écran des utilisateurs. Il couvre les modèles les plus utilisés, la plus ancienne version d'OS supportée, un petit écran, une tablette si l'application la prend en charge, et un Android à surcouche constructeur. Les émulateurs et simulateurs servent aux vérifications rapides sur chaque merge request, les vrais téléphones d'une ferme de terminaux à la campagne de nuit. Un lot court tourne sur beaucoup de modèles, la suite complète sur quelques-uns.
Signal d'alerteToute la suite sur les 40 téléphones à chaque commit, ou au contraire seulement sur le dernier iPhone de l'automaticien.
Question 4 · confirmé
Le test échoue au hasard quand une demande d'autorisation (notifications, localisation) apparaît. Comment le stabilisez-vous ?
Une bonne réponseIl décide de l'état des autorisations avant le test. Sur Android, la capability appium:autoGrantPermissions ou un adb shell pm grant au démarrage. Sur iOS, appium:autoAcceptAlerts ou, sur simulateur, la commande mobile: setPermission. Quand la demande fait partie du parcours, il l'attend explicitement et la traite comme une étape. Il choisit aussi en connaissance de cause entre noReset et fullReset, qui décident si l'application garde ses données entre deux sessions.
Signal d'alerteUn try/catch qui clique sur « Autoriser » s'il trouve le bouton, ou un Sleep avant chaque écran.
Question 5 · confirmé
Expliquez ce qui se passe entre votre script et l'application quand vous ouvrez une session Appium sur un iPhone.
Une bonne réponseLe client (Java, WebdriverIO, Python) envoie au serveur Appium une requête W3C WebDriver avec les capabilities : platformName, appium:automationName XCUITest, appium:udid, l'application ou son bundleId. Le serveur passe la main au driver XCUITest, qui installe et lance WebDriverAgent sur le téléphone. WebDriverAgent utilise le framework XCTest d'Apple pour piloter l'interface. Sur un vrai iPhone, il faut signer WebDriverAgent avec une équipe Apple. Sur Android, le driver UiAutomator2 installe de la même façon un serveur sur le téléphone via adb.
Signal d'alerte« Appium installe Selenium sur le téléphone », ou aucune idée de WebDriverAgent ni de la signature.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Ce que les recruteurs demandent sur le poste d'automaticien mobile
Appium, Espresso ou XCUITest : lequel mettre dans l'offre ?
Celui que l'équipe utilise ou veut utiliser. Appium convient quand une équipe qualité automatise iOS et Android avec un seul code de test. Espresso et XCUITest sont écrits dans le projet de l'application, souvent par les développeurs, et demandent Kotlin ou Swift. Si vous cherchez quelqu'un pour écrire les deux, dites-le : peu d'automaticiens viennent du développement natif, et le vivier se réduit nettement.
D'où viennent les bons automaticiens mobiles ?
Souvent du test web avec Selenium ou WebdriverIO, parfois du développement mobile, plus rarement du test manuel sur applications. Les premiers connaissent WebDriver et doivent apprendre les drivers, les autorisations et la signature iOS. Les seconds connaissent les plateformes mais ont moins l'habitude d'une suite tenue dans la durée. Demandez une application testée sur de vrais terminaux, avec le nombre de modèles et la durée de la suite.
Faut-il un Mac et des téléphones pour faire passer le test technique ?
Pas forcément. Une application de démonstration sur émulateur Android suffit pour juger les localisateurs, les attentes, les gestes et le code. L'exercice peut être complété par une discussion sur iOS : signature de WebDriverAgent, simulateur et vrai iPhone, autorisations. Si le poste porte surtout sur iOS, prévoyez un Mac avec Xcode, ou un compte d'essai sur une ferme de terminaux, pour la partie pratique.
Maestro peut-il remplacer Appium ?
Pour certaines équipes, oui. Maestro décrit les parcours dans des fichiers YAML, tolère mieux les délais d'affichage et se prend en main vite, sur Android et iOS. Appium reste plus répandu dans les offres, va plus loin sur les cas avancés (WebView, gestes complexes) et s'écrit dans un langage de programmation, avec objets écran et bibliothèques. Un automaticien Appium apprend Maestro vite. Un profil qui ne connaît que Maestro devra monter en compétence sur le code.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
