Antes de arrancar: este artículo ya estaba en mi calendario para más adelante. Lo adelanté porque una suscriptora me respondió al newsletter pidiendo justo este tema. Si me lees y quieres ver algo en este blog, escríbeme — leo todas las respuestas y, como ves, mueven mi calendario.
Llevo años hablando con QAs de muchos equipos y países. Y hay un patrón que se repite cada vez que toco el tema:
“Sí, mobile testing… eso lo dejamos para más adelante.”
Más adelante nunca llega.
Y mientras tanto, los usuarios finales están entrando a tu app desde un celular. Tú sabes que están. El equipo lo sabe. Pero la suite automatizada sigue siendo desktop-only, los bugs de mobile aparecen en producción, y el QA queda mal.
Quiero contarte por qué pasa esto, qué cambió en 2026, y cómo puedes empezar la semana que viene sin pelear con Java, Xcode ni emuladores que no arrancan.
Por qué evitamos mobile
No es por falta de ganas. Es por las 4 frustraciones que cualquier QA que intentó tocar mobile alguna vez puede listar de memoria:
1. El setup te roba 2 días antes del primer test
Para Appium en Android necesitas Java SDK, Android Studio, Android SDK, variables de entorno, drivers, certificados. Para iOS, además, una Mac, Xcode (15GB), un Apple ID configurado y certificados de desarrollador.
Y si todo eso funciona la primera vez, felicitaciones. Para el 90% restante, son días de pelea con appium driver doctor antes de poder escribir una sola línea de test.
2. La curva de aprendizaje no perdona
Los frameworks tradicionales de mobile testing usan WebDriver protocol. Necesitas saber programar (típicamente Java), entender específicos de cada plataforma, lidiar con selectores que cambian entre Android e iOS, y debuguear sin las herramientas a las que estás acostumbrado.
3. Los emuladores son lentos y los devices físicos cuestan
Un emulador Android decente arranca en 2-3 minutos. Un iPhone físico sale más caro que un servidor. Y si quieres testear en 5 modelos distintos, multiplica.
4. La docu asume que ya sabes
La mayoría de tutoriales empiezan con “asumiendo que tienes Appium instalado y un emulador corriendo…”. Si nunca lo hiciste, no tienes ni idea de cómo llegar a ese paso.
El resultado es predecible: el QA propone mobile, el lead dice “después”, y pasan 2 años. Cuando un usuario se queja en producción, la culpa cae en QA por no haberlo cubierto. Y nadie recuerda que el setup era un infierno.
Lo que cambió en 2026
La buena noticia: el ecosistema de mobile testing en 2026 no es el mismo de 2020. Hay 3 caminos según lo que necesites probar.
Camino 1: Mobile WEB (PWA, sitio responsive)
Si lo que tu equipo desarrolla es una PWA o un sitio web mobile-first, no necesitas un framework nuevo.
¿Qué es una PWA? Progressive Web App. Es una página web que se comporta como app: la instalas en el celular desde el navegador (sin pasar por App Store/Play Store), queda con ícono en el home, funciona offline y puede mandar notificaciones. Pero por debajo sigue siendo HTML + CSS + JavaScript. Ejemplos que ya conoces: Twitter/X mobile, Spotify Web, Pinterest, Notion, Starbucks. Si tu app tiene versión “instalable desde el navegador”, es PWA.
Playwright trae soporte de device emulation integrado. Configuras un proyecto con devices['iPhone 15'] o devices['Pixel 5'] y obtienes:
- Viewport correcto del device
- User agent mobile
- Touch events habilitados
- Density y deviceScaleFactor
Cero instalaciones nuevas. Si ya usas Playwright para desktop, agregas 5 líneas y tienes mobile web testing andando.
import { defineConfig, devices } from "@playwright/test";
export default defineConfig({ projects: [ { name: "chromium", use: devices["Desktop Chrome"] }, { name: "Mobile Chrome", use: devices["Pixel 5"] }, { name: "Mobile Safari", use: devices["iPhone 12"] }, ],});Limitación clave: Playwright emula un navegador móvil. No instala una app nativa, no accede a APIs del SO, no maneja gestos avanzados como swipe-to-delete. Para web mobile resuelve. Para apps nativas, no sirve.
Camino 2: Apps nativas con Maestro
Si tu equipo desarrolla apps nativas (iOS/Android) o híbridas (React Native, Flutter), Maestro es la entrada más amigable que existe en 2026.
Lo que lo hace diferente:
- YAML declarativo en vez de código. Compará:
# Maestro- launchApp- tapOn: "Login"- inputText: "user@test.com"- tapOn: "Continuar"- assertVisible: "Bienvenido"// Appium equivalentedriver.launchApp();driver.findElement(MobileBy.AccessibilityId("Login")).click();driver.findElement(MobileBy.AccessibilityId("email")).sendKeys("user@test.com");driver.findElement(MobileBy.AccessibilityId("Continuar")).click();Assert.assertTrue(driver.findElement(MobileBy.AccessibilityId("Bienvenido")).isDisplayed());- Built-in tolerance to flakiness — auto-retry y esperas inteligentes sin que las configures
- Funciona en Android, iOS, React Native, Flutter y web con la misma sintaxis
- Maestro Studio te deja grabar flows visualmente (como Codegen de Playwright pero para mobile)
- Cross-platform conditional flows built-in:
when: platform: Androidvswhen: platform: iOS
¿Por qué no era una opción antes? Porque Maestro es relativamente nuevo (mobile.dev lo lanzó hace pocos años). En 2026 ya está maduro.
Camino 3: Appium (cuando ya está implantado)
Appium sigue siendo el estándar de la industria, especialmente en empresas grandes con stack legacy. Si tu equipo ya tiene Appium funcionando, no hay razón para migrar por moda.
Pero para empezar mobile testing de cero en 2026, ya no es la mejor opción. La curva es alta y los caminos 1 y 2 cubren la mayoría de casos con muchísimo menos sufrimiento.
La pregunta de pivote
Antes de elegir herramienta, haz esta pregunta:
¿Mi app es web mobile (PWA, sitio responsive) o app nativa (instalable desde App Store/Play Store)?
Si es web mobile → Playwright con device emulation. Cero setup nuevo.
Si es nativa o híbrida (Capacitor, Cordova, React Native, Flutter) → Maestro. Setup mínimo, sintaxis YAML.
Si tu empresa ya usa Appium → sigue con Appium, no rompas lo que funciona.
Cuándo cada uno: la matriz rápida
Cómo empezar SIN comprar nada
Esta es la parte que más me piden y nadie cuenta:
Para mobile web (Playwright):
- Cero costos. Cero instalaciones nuevas. Si tu equipo ya tiene Playwright, agregas un proyecto en
playwright.config.tsy ya. - Tiempo a primer test: 5 minutos.
Para apps nativas (Maestro):
- Maestro CLI: gratis, instalación de 1 comando
- Emulador Android: gratis con Android Studio
- iOS Simulator: gratis con Xcode (necesitas Mac)
- Tiempo a primer test: 30 minutos, incluyendo descargar el emulador
No necesitas device físico para empezar. No necesitas contratar un servicio de farm de devices. No necesitas invertir un peso. Lo que necesitas es decidir empezar.
Si no tienes Mac y quieres testear iOS — Maestro Cloud te ejecuta los tests en iOS desde Windows/Linux por una suscripción mensual. Para arrancar y validar que el camino sirve, alcanza con Android local + emulador.
Lo que viene en este blog
Esta es la primera pieza de una mini-serie sobre mobile testing. En los próximos días publico las 2 guías prácticas con código:
→ Tu primer test de mobile WEB en 10 minutos con Playwright — quick win usando lo que ya conoces. Setup cero, ejemplo real, listo para llevarlo a tu proyecto.
→ Tu primer test de app NATIVA en 30 minutos con Maestro — instalación, primer flow.yaml, gestos básicos, integración con CI. Sin Java, sin Xcode (en Android), sin sufrir.
Si te interesa la serie, suscríbete al newsletter — los suscriptores reciben cada guía antes de que aparezca en LinkedIn.
La reflexión final
Mobile testing es el gap más grande que veo en suites de QA. Y no es porque los QAs no quieran hacerlo. Es porque arrancar fue difícil durante años, los tutoriales asumen demasiado, y nadie habla del costo emocional de pelear con un setup que no funciona.
En 2026 hay caminos más cortos. Maestro bajó la barrera de las apps nativas. Playwright resolvió mobile web sin pedirte nada nuevo.
Si tu app tiene tráfico mobile y todavía no lo automatizas — esta es tu señal.
No es difícil. Es que nadie te lo cuenta sin asumir que ya sabes.