Tu primer test mobile en 30 minutos — sin Java, sin Xcode, sin sufrir

Hoy bajamos a tierra. Pero antes del primer comando, te quiero contestar la pregunta honesta que cualquier QA se hace cuando ve “guía de mobile testing”: ¿esto va a funcionar el lunes en mi proyecto, o es teoría con app de juguete?

Spoiler: lo que vas a hacer en los próximos 30 minutos es testing real, sobre una app real (Wikipedia oficial, 4M downloads), con la sintaxis exacta que vas a escribir cuando un dev te pase el APK de tu producto. Lo único que cambia entre esta guía y tu trabajo del lunes son tres líneas. Te las marco al final.

¿Por qué mobile testing AHORA?

El dato que me sigue rompiendo la cabeza, lo digo otra vez porque hace falta:

Esa brecha entre cómo se usa el software hoy y cómo lo testeamos no se cerró sola en 15 años de disciplina QA. Tres razones se repiten en cada equipo con el que trabajé:

1. Setup pesado — Java, Android Studio, certificados firmados, Xcode con sus 50 GB, simuladores que rompen al actualizar macOS.
2. Stack fragmentado — Appium para enterprise legacy, Detox solo para React Native, Espresso solo para devs Android, XCUITest solo para devs iOS. Ninguno cross-platform real, ninguno apuntado al QA que no es dev mobile.
3. Tooling pensado para devs, no para QAs — los frameworks asumen que sabes Kotlin o Swift. La curva de entrada es alta justo donde el QA debería poder agregar valor sin pelearse con compiladores.

Lo que cambió en 2026 — y por eso esta guía sale ahora y no hace dos años — es que apareció una herramienta que abstrae las tres barreras a la vez: Maestro. Declarativo, cross-platform, sin SDK que importar. Tú describes en YAML qué quiere el test (tap, scroll, assert), Maestro se encarga del cómo. Es la misma filosofía que Cypress aplicó a web hace 7 años — abstraer la fricción para que el QA dedique el tiempo a pensar, no a configurar.

Maestro vs Appium vs Detox — la decisión rápida

No voy a hacer comparativa de 30 features porque la mayoría no las vas a usar nunca. Esta es la decisión real que tomas en 30 segundos:

El resto de la guía es 100% Maestro. Si tu situación es distinta, las próximas guías de la serie van a cubrir Playwright para mobile web y Appium para casos enterprise.

1. Setup mínimo en 5 minutos

Maestro tiene dos componentes que se instalan por separado y vas a usar ambos:

• Maestro CLI — el motor que corre los tests. Es lo que te hace falta para que maestro test mi-flow.yaml funcione.
• Maestro Studio Desktop — la GUI nativa para inspeccionar elementos visualmente. La instalamos en la sección 5.

Por ahora, el CLI.

Instala la CLI

curl -fsSL "https://get.maestro.mobile.dev" | bash

El instalador descarga el binario a ~/.maestro/bin/maestro. Cuando termina te pide que agregues esa ruta a tu PATH. Hazlo persistente:

echo 'export PATH="$HOME/.maestro/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

Verifica:

maestro --version

Esperas algo tipo 2.5.1 (la versión al momento de escribir esta guía). Anótala — la usamos al final como referencia de stack.

Levanta un emulador con Maestro

Acá viene el primer truco que cambia tu vida si nunca trabajaste con Android nativo. El camino tradicional para tener un emulador funcionando es:

1. Instalar Android Studio (~5 GB)
2. Abrir el AVD Manager
3. Crear un Virtual Device eligiendo entre 30 opciones de hardware
4. Descargar una System Image específica (~1-2 GB por API level)
5. Configurar el AVD
6. Lanzarlo

Con Maestro, todo eso se reduce a un comando:

maestro start-device --platform android

Si tienes Android SDK instalado en tu Mac (lo más probable si trabajaste en QA antes), Maestro detecta lo que tienes, te avisa qué falta, te pregunta si quieres instalarlo, y lo descarga solo. Te crea un Pixel 6 con API 33 con defaults sensatos. Tiempo total: 2-3 minutos la primera vez (mayoría es download de la system image), 30 segundos las siguientes.

Cuando el emulador termina de bootear, vas a tener una ventana flotando con un Pixel 6 mostrando la pantalla principal de Android. Eso es tu device de testing — todos los flows que escribas a partir de ahora corren ahí.

Baja los samples oficiales

Maestro publica un set de apps + flows de ejemplo que vamos a usar como punto de partida. Bájalos:

maestro download-samples

Eso crea una carpeta samples/ en tu directorio actual con:

• sample.apk y wikipedia.apk — la app oficial de Wikipedia (sí, vamos a usar Wikipedia real para testear)
• android-flow.yaml — el flow más mínimo posible (5 líneas)
• android-advanced-flow.yaml — un flow con selectores avanzados, scripts, subflows
• subflows/ — flujos modulares reutilizables (onboarding, cleanup)
• Sus equivalentes para iOS

2. Tu primer flow — 5 líneas que ya son testing real

Antes de escribir el tuyo, lee el más simple que Maestro te bajó:

cat samples/android-flow.yaml

Vas a ver esto, literal:

appId: org.wikipedia
tags:
  - android
  - passing
---
- launchApp

Eso es todo el archivo. Cinco líneas. Anatomía:

Comparalo mentalmente con cómo sería esto en Appium: 50 líneas de Java, page objects, drivers, capabilities, before/after hooks. Esa diferencia es la promesa de Maestro hecha texto.

Corre el smoke test

maestro test samples/android-flow.yaml

Mantén visible la ventana del emulador mientras corre. Vas a ver Wikipedia abrirse sola. La terminal te muestra:

Running on Maestro_ANDROID_pixel_6_android-33
> Flow: android-flow
✅ Launch app "org.wikipedia"
Flow Passed

Ese check verde + la app booteada en simultáneo es el momento “ah, ENTIENDO Maestro”. Escribiste cinco líneas, le diste una orden, el emulador la ejecutó. Sin SDK, sin código, sin compilar nada.

Escribe tu propio flow — caso real

Un smoke test no enseña selectores ni gestos. Vamos a escribir uno que ejerza la API real de Maestro: búsqueda + tap en resultado + scroll + assert.

Crea mi-flow.yaml en la carpeta samples/:

appId: org.wikipedia
tags:
  - android
  - mi-primer-flow
---
# 1. Skip onboarding (subflow oficial Maestro)
- runFlow: subflows/onboarding-android.yaml

# 2. Screenshot post-onboarding
- takeScreenshot: 01-home

# 3. Tap en search bar — ID estable a i18n y redesigns
- tapOn:
    id: "org.wikipedia:id/search_container"

# 4. Screenshot del buscador abierto
- takeScreenshot: 02-search-open

# 5. Query — "Software testing" porque la app está en inglés
- inputText: "Software testing"

# 6. Espera explícita — la lista de resultados tiene animación de entrada
- waitForAnimationToEnd

# 7. Screenshot con resultados
- takeScreenshot: 03-search-results

# 8. Tap en el TÍTULO del primer resultado, NO en la search bar
- tapOn:
    id: "org.wikipedia:id/page_list_item_title"
    index: 0

# 9. Espera a que cargue el artículo
- waitForAnimationToEnd

# 10. Valida que el artículo cargó (título visible en el body)
- assertVisible: "Software testing"

# 11. Screenshot del artículo cargado
- takeScreenshot: 04-article-loaded

# 12. Scroll para mostrar más contenido
- scroll

# 13. Screenshot post-scroll
- takeScreenshot: 05-article-scrolled

Corre:

maestro test samples/mi-flow.yaml

Y mientras corre, mira el emulador. Vas a ver:

1. La app se relanza al estado inicial
2. El subflow de onboarding salta solo
3. Tap en el buscador → se abre el panel
4. “Software testing” se tipea letra por letra
5. Aparece la lista de resultados
6. Tap en el primer resultado → carga el artículo
7. Scroll → ves el contenido bajando

Y en HOME aparecen 5 archivos PNG numerados — tus screenshots automáticos. Esa automatización del capture es lo que cambia el workflow del QA: en lugar de screenshotear manual durante la corrida, le pides a Maestro que lo haga. Asset libre.

Acá los tienes en secuencia — la salida exacta que produjo el flow que acabas de correr:

Cinco PNG generados sin escribir una sola línea de captura manual. Y cuando algo falla mañana en CI, esos screenshots son la primera evidencia que vas a leer antes de abrir el log.

Cuando un test verde te miente

Acá viene la sección estrella de la guía — la lección que NINGÚN tutorial en inglés te va a dar porque nadie se permite mostrar un bug en el camino.

La primera versión de este flow que escribí tenía un query distinto: "Pruebas de software" (en español) en lugar de "Software testing" (en inglés). Y el tapOn del paso 8 era por texto: tapOn: "Pruebas de software".

El test pasó. Verde 13/13. Pero los screenshots NO mostraban un artículo de Wikipedia — mostraban una página de resultados de búsqueda con artículos sin relación: “Fluid Attacks”, “Colombia”, “Karina Milei”, “Pengo (video game)”. El artículo nunca cargó.

Tres bugs en uno, vivientes en el mismo flow:

La fix está incorporada en el flow de arriba — usé id: "org.wikipedia:id/page_list_item_title" con index: 0 para tapear específicamente el TÍTULO del primer resultado, no cualquier texto que coincida. Y cambié el query a inglés para que matchee con el contenido real de Wikipedia EN.

La regla para mobile testing que va a cambiar cómo escribes flows el resto de tu carrera: prioriza selectores en este orden, siempre.

1. ID Android nativo (com.empresa.app:id/login_btn) — sobrevive a i18n, redesigns, A/B tests
2. Accessibility ID — semánticamente significativo, también estable
3. Texto único en pantalla — solo si garantizas que NO se repite en otro lugar
4. NUNCA coordenadas, filenames, o “el texto del botón en el idioma del momento”

3. Maestro Studio Desktop — tu copiloto QA

Si llegaste hasta acá, ya escribiste YAML a mano y entiendes cada línea. Ahora podemos meter una herramienta que ACELERA esa escritura sin reemplazarla: Maestro Studio Desktop.

Studio es una app nativa con cuatro funciones que cambian el aprendizaje:

1. Inspeccionar elementos visualmente — clickeas un botón en el mirror del emulador y Studio te tira los selectores disponibles (ID, accessibility ID, text, coordenadas)
2. Click-to-insert — posicionas el cursor en tu YAML, clickeas el elemento, Studio te inserta el step con el selector correcto
3. Run desde la app — corres tests sin volver a la terminal
4. MaestroGPT — autocomplete inteligente que conoce la jerarquía de tu app

Instala Maestro Studio Desktop

Otra vez: NO con brew. El cask maestro de brew es un producto distinto sin relación. Bájalo del sitio oficial:

curl -fLo ~/Downloads/MaestroStudio.dmg https://studio.maestro.dev/MaestroStudio.dmg
open ~/Downloads/MaestroStudio.dmg

En Finder, arrastra Maestro Studio a Applications. Lánzala:

open -a "Maestro Studio"

Anatomía de Studio Desktop

Cuando abre, vas a ver:

• Dropdown “Select device” arriba a la izquierda — lista los emuladores/devices disponibles
• Mirror del emulador en el panel izquierdo (después de seleccionar device)
• Editor central — tus flows YAML abiertos como pestañas
• File tree derecho — los archivos del workspace
• Botones inferiores — Local/Cloud toggle, Run Test, Run All Tests

A diferencia de la web, Studio Desktop NO autodetecta el device automáticamente — tienes que abrir el dropdown y seleccionarlo manualmente la primera vez. Pequeña regresión UX que se compensa con todo lo que viene después.

El click-to-insert workflow

Esto es lo que vale la app:

1. Abre tu flow en el editor central. Posiciona el cursor en la línea donde quieres insertar un step nuevo.
2. Clickeá un elemento en el mirror del emulador (un botón, una imagen, un texto).
3. Studio te muestra un popup con 3+ opciones de selector + un menú de acciones (Insert, Insert & Run, Copy, View Docs).
4. Click en Insert → te pega el step en el cursor con el selector que elegiste.
5. Click en Insert & Run → lo pega Y lo corre en el emulador inmediatamente para validar.

Ese loop “veo elemento → click → step generado → run inmediato” es el momento donde Maestro deja de ser una CLI y se vuelve un IDE de mobile testing.

Comparación que justifica todo: Web vs Desktop

Mismo elemento — la imagen de portada del artículo Software testing en Wikipedia. Selectores que cada versión de Studio sugiere:

La web te ofrecía los DOS peores selectores que existen — un filename largo y coordenadas porcentuales. Cualquiera de los dos rompe tu test al primer cambio de imagen o de pantalla.

La Desktop te tira el ID Android real y semántico que Wikipedia usa internamente (view_page_header_image). Ese ID está hardcoded en el código fuente de Wikipedia — sobrevive a redesigns, a updates, a cambios de contenido.

Cuándo Studio te miente — sí, también la Desktop

Studio Desktop es buenísima, pero NO es magia. Si la app que testeás no expuso IDs semánticos en sus elementos (te puede pasar con apps legacy o con ProGuard activado), Studio Desktop también te va a sugerir coordenadas. Tu cerebro QA sigue siendo el filtro final.

Tres preguntas para evaluar cualquier sugerencia de Studio:

1. ¿Este selector va a sobrevivir al próximo refactor de UI?
2. ¿Este selector tiene sentido semántico (ID legible) o es un accidente (:id/a, :id/b)?
3. Si NO hay buen selector, ¿estoy testeando el elemento correcto, o debería testear otro elemento más estable cerca?

A veces la respuesta correcta es NO escribir el assert sobre ese elemento y elegir uno mejor. Studio te ofrece todas las formas de tapear lo que clickeaste — tú eliges cuál sobrevive.

4. Llevarlo al CI — la próxima guía

Hasta acá tu loop es escribir flow → correr local → ver verde. Eso te alcanza para usar Maestro el lunes en tu máquina. Pero el valor real aparece cuando esos tests corren solos en cada PR, sin que tengas que abrir un emulador a mano.

CI mobile tiene su propio set de trampas — emulador headless en GitHub Actions, timeouts agresivos por boot lento, cómo subir screenshots como artifacts cuando un test falla, cuándo conviene pagar Maestro Cloud en lugar de pelearse con runners propios — y por eso merece su propia guía dedicada, no un anexo apurado acá.

Mientras tanto, lo de la sección 5 te alcanza para arrancar mañana mismo con la app de tu proyecto. CI ya tiene su propia guía (link arriba), pero el smoke test funcionando local es el prerequisito — no te saltees el local para correr al CI.

5. De Wikipedia a TU app — el bridge profesional

Lo más importante de esta guía no es que sepas testear Wikipedia. Es que el patrón que aprendiste se transfiere 1:1 a la app real que un dev te va a pasar el lunes. Para que no te quedes paralizado cuando llegue ese momento, te dejo el workflow exacto.

Lo que cambia, lo que NO

Cuando recibes un APK de tu equipo dev, comparado con lo que hicimos hoy, solo cambian tres cosas:

Todo lo demás es exactamente lo mismo. YAML, Studio Desktop, gestos, assertions, screenshots, scroll — idéntico.

Los 5 pasos del workflow real

Paso 1 — Recibes el archivo. Te llega app-debug.apk por Slack, mail, link de Drive, o como artifact del CI. Guárdalo en una carpeta limpia: ~/Proyectos/qa-tu-app/builds/.

Paso 2 — Identifica el appId (package name).

# Opción A: preguntale al dev (más rápido)
# Opción B: leelo del APK
aapt dump badging app-debug.apk | grep package
# Te tira: package: name='com.empresa.tuapp' versionCode='42'

Paso 3 — Instala el APK en el emulador.

adb install app-debug.apk

Si te tira INSTALL_FAILED_INSUFFICIENT_STORAGE, borra apps innecesarias. Si te tira INSTALL_FAILED_VERSION_DOWNGRADE, primero adb uninstall com.empresa.tuapp.

Paso 4 — Descubre los selectores con Studio Desktop. Abres Maestro Studio, seleccionas tu device, tu app, haces hover sobre los elementos del flow que vas a testear, y copias los selectores que te sugiere. La parte que en Wikipedia adivinábamos por convención (org.wikipedia:id/search_container), acá la inspeccionas directo.

Paso 5 — Escribe el flow con la MISMA plantilla que ya conocés:

appId: com.empresa.tuapp
---
- launchApp
- tapOn:
    id: "com.empresa.tuapp:id/login_btn"
- inputText: "test@empresa.com"
- tapOn:
    id: "com.empresa.tuapp:id/password_field"
- inputText: "password123"
- tapOn:
    id: "com.empresa.tuapp:id/submit"
- assertVisible: "Bienvenido"

Y corres maestro test mi-flow.yaml. Mismo runner, misma terminal, mismo verde.

Las 3 trampas reales cuando recibas el APK de tu equipo

AAB en lugar de APK — Si el dev te pasa un .aab (Android App Bundle), Maestro no lo instala directo. Necesitas bundletool para extraer APKs, o pídele al dev el debug APK. La mayoría de equipos publican AABs a Play Store pero generan APKs para QA — pídelos.

Apps con obfuscación (ProGuard/R8) — En release builds, los IDs de recursos quedan obfuscados (com.empresa:id/a, :id/b). Los IDs Android no sirven ahí. Solución: pídele al equipo dev una debug build sin obfuscation (es la práctica estándar para QA). Si no se puede, los selectores por accessibility ID sobreviven a la obfuscación — coordina con dev que los pongan en los elementos críticos.

iOS en lugar de Android — Los pasos cambian: en lugar de .apk recibes .app bundle (para Simulator) o .ipa (para device). En lugar de adb install usas xcrun simctl install. El resto del flow YAML es 95% idéntico — esa es la ventaja de Maestro cross-platform.

Cierre — qué tienes ahora

Si seguiste la guía completa, en estos 30 minutos pasaste de cero a:

• ✅ Maestro CLI instalado y verificado
• ✅ Un emulador Android funcionando, manejado por Maestro (sin abrir Android Studio)
• ✅ Tu primer flow YAML corriendo (smoke test + flow custom de 13 pasos)
• ✅ Maestro Studio Desktop con click-to-insert para inspeccionar selectores semánticos
• ✅ El workflow profesional para cuando recibas un APK de tu equipo dev
• ✅ La regla de selectores que va a guiarte el resto de tu carrera mobile QA

Lo más importante: tienes un patrón repetible. La próxima feature mobile de tu proyecto sale por exactamente los mismos pasos. Y los bugs sutiles que estabas dejando pasar en mobile (selectores ambiguos, falsos positivos por i18n, screenshots mintiendo en CI) ahora los puedes cazar antes de que lleguen a producción.

Qué leer / hacer después

1. Aplícalo el lunes — ve con el APK debug de tu producto. La sección 5 te dice exactamente cómo. Si te trabas, escríbeme.
2. Siguiente pieza de la serie (ya publicada): “Maestro en CI con GitHub Actions — del editor a producción sin tocar emuladores manuales nunca más”. Workflow.yml verificado con 3 runs reales sobre un repo público forkeable. Cierra la serie Mobile Testing.
3. Para mobile WEB (no nativo) — Playwright tiene mobile emulation cero-fricción. Esa es otra guía pendiente: cómo testear sitios web y PWAs en vista mobile sin levantar emulador nativo.