Cómo empezar a testear apps móviles con Appium

Casi todo lo que se enseña sobre automatización de testing en español está pensado para web: Selenium, Cypress, Playwright. Pero una parte real del trabajo de QA consiste en probar aplicaciones que no se abren en un navegador, sino que se instalan en un móvil.

Appium es la herramienta que cubre ese hueco. Lleva más de una década siendo la opción de referencia para automatizar apps Android e iOS, y sigue siéndolo: reutiliza el mismo protocolo que ya conoces si vienes de Selenium, así que el salto es más pequeño de lo que parece.

En este artículo ves qué es Appium, en qué se diferencia probar una app móvil de probar una web, cómo montar tu primer entorno y un test real completo, paso a paso. Al final, los datos honestos sobre cuánto se pide de verdad en las ofertas de QA en España, sacados de nuestra propia bolsa de empleo.

Por qué probar una app móvil no es lo mismo que probar una web

Antes de tocar herramientas conviene tener claro qué cambia de verdad. No es solo "lo mismo pero en una pantalla más pequeña": el modelo entero es distinto.

Qué es Appium y por qué sigue siendo la referencia

Appium es un framework de automatización de código abierto que permite escribir un test y ejecutarlo contra apps nativas, híbridas o web móvil, en Android e iOS. No inventa un protocolo propio: se apoya en WebDriver, el mismo estándar que usa Selenium para navegadores, extendido con capacidades específicas de móvil.

Funciona como un intermediario. Tu test (en Python, Java, JavaScript o el lenguaje que uses) envía comandos a un servidor Appium que corre en local, y ese servidor los traduce y se los pasa al framework de automatización nativo de cada sistema: UiAutomator2 en Android, XCUITest en iOS. Tú no hablas directamente con el dispositivo, hablas con Appium y Appium habla con el sistema operativo.

Cómo montar tu primer entorno con Appium

Esta guía usa Android porque no requiere un Mac. El proceso con iOS es equivalente, cambiando el driver y sustituyendo Android Studio por Xcode.

Necesitas Node.js instalado (Appium corre sobre Node), el servidor de Appium, el driver de la plataforma y el cliente del lenguaje que vayas a usar para escribir los tests. Aquí, Python:

npm install -g appium
appium driver install uiautomator2
pip install Appium-Python-Client

Además necesitas un emulador Android corriendo (se crea desde el AVD Manager de Android Studio) y el archivo .apk de la app que quieres probar. Con eso listo, arrancas el servidor de Appium en una terminal aparte:

appium

El servidor queda escuchando en http://127.0.0.1:4723. Ahora sí, un test real que abre la app, rellena un campo de usuario, pulsa el botón de acceso y comprueba que aparece un mensaje de bienvenida:

from appium import webdriver
from appium.options.android import UiAutomator2Options

options = UiAutomator2Options()
options.platform_name = "Android"
options.automation_name = "UiAutomator2"
options.device_name = "emulator-5554"
options.app = "/ruta/a/mi-app.apk"

driver = webdriver.Remote("http://127.0.0.1:4723", options=options)

campo_usuario = driver.find_element("id", "com.miapp:id/username")
campo_usuario.send_keys("usuario_prueba")

boton_login = driver.find_element("id", "com.miapp:id/btn_login")
boton_login.click()

mensaje = driver.find_element("id", "com.miapp:id/welcome_text")
assert "Bienvenido" in mensaje.text

driver.quit()

Para saber qué id tiene cada elemento sin adivinar, se usa Appium Inspector: una app de escritorio que se conecta a tu emulador y te deja hacer clic sobre cualquier elemento en pantalla para ver su localizador exacto, igual que las herramientas de desarrollador de un navegador hacen con el HTML.

Errores comunes al empezar con Appium

• Usar xpath cuando existe un id o accessibility id. El xpath es el localizador más frágil en móvil: cualquier cambio de layout lo rompe, más incluso que en web.
• No esperar a que cargue la app antes de buscar elementos. Una espera fija con sleep es lenta cuando sobra y falla igual cuando falta. Las esperas explícitas de Appium resuelven esto de forma fiable.
• Automatizar gestos con coordenadas absolutas. Un swipe calculado a píxeles fijos para un tamaño de pantalla se rompe en cuanto se ejecuta en otro dispositivo distinto.
• Probar solo en emulador. El emulador detecta la mayoría de bugs funcionales, pero no problemas reales de rendimiento, batería o sensores que solo aparecen en hardware físico.
• Hardcodear el nombre del dispositivo o la ruta del .apk. Un valor que solo existe en tu máquina rompe el test en cuanto lo ejecuta otra persona o corre en CI/CD.

Dónde encaja Appium en tu progresión como QA

Aquí conviene ser honestos con los datos en vez de vender la herramienta de moda. De las 105 ofertas de QA activas que teníamos agregadas para la bolsa de empleo de 17lab el 7 de septiembre de 2026, solo 6 (un 5,7%) mencionaban Appium. Selenium, Cypress y Playwright aparecen muchas más veces: la comparativa completa está en Playwright vs Cypress vs Selenium: cuál elegir en 2026.

Lo más revelador no es el porcentaje, es el patrón: en esas 6 ofertas, Appium nunca aparecía en solitario. Siempre iba acompañado de al menos otra herramienta de automatización web (Selenium, Cypress o Playwright, según el caso). Es coherente con lo que se ve en la práctica del sector: primero se aprende a automatizar web, y Appium se añade después, cuando el equipo tiene también producto móvil que probar.

Si estás empezando de cero, el orden con más sentido pasa primero por una base de automatización general, algo que ya cubre curso-automatizacion-qa con una vista panorámica de Cypress, Playwright, Selenium y Appium, para decidir con criterio dónde profundizar en vez de aprender Appium aislado sin haber escrito antes un test automatizado.