Una estrategia de pruebas móviles es el orden en el que decides qué probar, no la lista de dispositivos en los que lo pruebas. La mayoría de los equipos crea primero la lista: una hoja de cálculo con iPhones, Samsungs y versiones de sistema operativo. Esa hoja de cálculo es un resultado. La estrategia son las cuatro decisiones que la producen, y equivocarse en el orden es la razón por la que los equipos acaban con una amplia cobertura de dispositivos sobre los riesgos equivocados.
¿Qué es una estrategia de pruebas de aplicaciones móviles?
Es la estructura de decisiones que determina qué se prueba, en qué orden y quién da el visto bueno, antes de que nadie abra un laboratorio de dispositivos. Eso es distinto de una lista de comprobación de pruebas de aplicaciones móviles, que responde a “qué verificamos en esta build”. Una estrategia responde primero a una pregunta más difícil: qué fallos nos costarían dinero de verdad y quién detecta cada uno antes de que llegue a producción.
La mayoría de las guías publicadas sobre este tema empiezan con “elige tus dispositivos” y tratan la matriz como si fuera la estrategia en sí. Es al revés. Una matriz de dispositivos creada primero suele reflejar la cuota de mercado de las tiendas de aplicaciones en lugar del riesgo real de tu aplicación. Acabas siendo exhaustivo en dispositivos y escaso justo en el fallo que te habría costado el lanzamiento.
Decisión 1: qué fallos te costarían dinero de verdad
Antes que nada, clasifica los tipos de fallo que importan para esta aplicación concreta:
- Cierre inesperado al iniciar o en el primer uso. Frena la activación antes de que el usuario se forme una opinión del producto.
- Fallo en el pago. Pérdida directa de ingresos, más el coste de soporte y reembolsos que viene después.
- Pérdida o corrupción de datos. Destruye la confianza de inmediato, sobre todo en cualquier aplicación que gestione contenido generado por los usuarios o el estado de la cuenta.
- Rechazo en la tienda. Apple y Google rechazan aplicaciones por motivos que no tienen que ver con bugs (metadatos, redacción de los permisos, manifiestos de privacidad), y un rechazo en el peor momento puede costarte por completo una fecha de lanzamiento.
Clasifícalos para tu aplicación, sin tratarlos como igual de probables o igual de caros. A una aplicación de suscripción le preocupa sobre todo el fallo en el pago. A una red social, la pérdida de datos. Un primer lanzamiento ante un público que aún no te conoce teme sobre todo el rechazo en la tienda, porque no hay buena voluntad acumulada que aguante un retraso. Esta clasificación es la primera sección del documento de estrategia, y es la que la mayoría de los equipos se salta porque parece una conversación de negocio, no de QA. Es ambas cosas.
Decisión 2: qué capa detecta cada tipo de fallo al menor coste
Una vez que sabes qué sale caro, decide dónde se detecta cada tipo de fallo antes de que llegue a un usuario. El mismo bug cuesta distinto según dónde se encuentre:
Cierre inesperado al iniciar
Se ejecuta en minutos y bloquea la build antes de que llegue a un dispositivo
Fallo en el pago
Pruebas exploratorias manuales con pasarelas de pago reales
Los entornos sandbox no reproducen los rechazos de tarjeta ni los reintentos del mundo real
Pérdida de datos
Pruebas de integración contra el backend real
Las pruebas unitarias simulan la base de datos; el bug vive en el traspaso
Rechazo en la tienda
Revisión manual de políticas antes del envío
Ninguna capa automatizada lee por ti las directrices vigentes de Apple o Google
Es una decisión de ubicación, no de automatización. Te dice si un riesgo pertenece a una fase temprana (rápida, automatizada, barata) o a una posterior (más lenta, manual, pero la única capa que realmente lo ve). Para ver cómo se distribuyen estas capas a lo largo del calendario de un lanzamiento, consulta nuestra guía sobre las fases de las pruebas de software. Construir la automatización en sí es una decisión aparte, con sus propias ventajas e inconvenientes, que merece su propia conversación una vez resuelta esta ubicación.
Decisión 3: quién decide sobre una build dudosa
Cada lanzamiento tiene al menos una build que no es claramente apta ni claramente no apta para publicarse. Un cierre inesperado menor en una versión antigua del sistema operativo. Un caso límite de pago que solo se da con un tipo de tarjeta. Alguien tiene que ser responsable de esa decisión antes de que ocurra, no durante las prisas del día del lanzamiento.
Nombra el rol, no a una persona: normalmente el responsable de ingeniería para el riesgo técnico, el PM para el riesgo de negocio, y una vía de escalado acordada para cuando no estén de acuerdo. Ponlo por escrito. Los equipos que salen escaldados no son los que tienen mal criterio, sino aquellos en los que la decisión dudosa la toma quien esté en la sala en ese momento, con prisas y sin un acuerdo previo sobre qué significa “riesgo aceptable” para esta aplicación. Aquí también importa el papel de un socio de QA: la decisión se toma más rápido cuando QA trabaja como un solo equipo con ingeniería y producto, en lugar de como un proveedor que entrega una lista de bugs y espera.
Decisión 4: ahora sí puedes construir la matriz de dispositivos
Con las tres primeras decisiones tomadas, la matriz de dispositivos se convierte en un ejercicio sencillo: qué dispositivos y versiones de sistema operativo representan de verdad los riesgos que clasificaste en la decisión 1, probados en la capa que asignaste en la decisión 2. Un riesgo de fallo en el pago implica probar en las versiones de sistema operativo y los dispositivos en los que tu SDK de pagos se comporta de forma distinta, no en los diez teléfonos con más cuota de mercado. Un riesgo de rechazo en la tienda implica probar con las versiones de sistema operativo sobre las que Apple y Google aplican sus políticas en ese momento, algo que cambia cada año.
Aquí es también donde la matriz se mantiene pequeña a propósito. Una matriz construida a partir del riesgo cubre menos dispositivos que una construida a partir de la cuota de mercado, y de eso se trata. Cada dispositivo que se añade sin un riesgo detrás es cobertura que pagas y no usas.
La estructura del documento de estrategia de pruebas
Un documento de estrategia de pruebas de aplicaciones móviles no tiene por qué ser largo. Ocho secciones, con una línea de orientación cada una, bastan para que un PM lo complete esa misma tarde:
- Tipos de fallo clasificados – el orden por coste económico de la decisión 1, específico de esta aplicación.
- Asignación de capas – qué tipo de fallo se detecta en qué capa, según la decisión 2.
- Responsable de las builds dudosas – el rol y la vía de escalado, según la decisión 3.
- Matriz de dispositivos y sistemas operativos – el resultado de la decisión 4, vinculado a los riesgos clasificados.
- Criterios de paso a producción – qué debe cumplirse para que una build se publique, en lenguaje claro.
- Alcance de la regresión por lanzamiento – qué se vuelve a comprobar cada vez y qué solo en cambios importantes.
- Exclusiones conocidas – qué deja fuera esta estrategia a propósito, y por qué.
- Frecuencia de revisión – cuándo se revisa este documento (un nuevo proveedor de pagos, una nueva versión del sistema operativo, un lanzamiento fallido).
Cuándo flexibilizar este orden
Esta secuencia de cuatro decisiones da por hecho una aplicación con usuarios reales y dinero real en juego. Es excesiva para una herramienta interna o un prototipo desechable, donde “probar el camino feliz y publicar” es la respuesta honesta. También da por hecho que alguien está dispuesto a mantener la conversación sobre el coste de la decisión 1, lo que exige tener a producto e ingeniería en la misma sala. Si esa conversación no puede darse, la estrategia volverá a ser una lista de dispositivos, porque una lista de dispositivos es lo que queda cuando nadie quiere clasificar lo que de verdad importa.
Cómo lo construye QAwerk contigo
QAwerk ha completado más de 300 proyectos de QA, y un patrón que se repite en ellos es que los equipos que pasan directamente a la matriz de dispositivos gastan el presupuesto de pruebas en el riesgo equivocado. BeFamily llegó a QAwerk con una aplicación totalmente nueva: el equipo redactó los planes de prueba, creó más de 500 escenarios de prueba y probó las nuevas builds en 9 dispositivos. Desde su lanzamiento, BeFamily no ha tenido ningún cierre inesperado ni problema grave en producción, y sus usuarios activos se triplicaron en una semana.
Esa es la diferencia entre un proveedor de QA que ejecuta una lista de comprobación y un equipo que trabaja contigo las decisiones 1 y 3 antes de escribir un solo caso de prueba. Si vas a poner en marcha pruebas de aplicaciones móviles por primera vez, o heredas un proceso que no detecta lo que importa, ahí es donde debe empezar la conversación, no con los teléfonos.
¿Qué es una estrategia de pruebas de aplicaciones móviles?
Es el orden de decisiones que hay detrás de un esfuerzo de pruebas: qué fallos importan más por su coste, qué capa de pruebas detecta cada uno al menor coste, quién da el visto bueno a una build dudosa y, solo entonces, qué dispositivos y versiones de sistema operativo se prueban. No es la lista de dispositivos en sí, ni la lista de comprobación de lo que hay que verificar en cada funcionalidad.
¿Qué debe incluir un documento de estrategia de pruebas de aplicaciones móviles?
Ocho secciones lo cubren: tipos de fallo clasificados, asignación de capas por tipo de fallo, el responsable de las builds dudosas y la vía de escalado, la matriz de dispositivos y sistemas operativos, los criterios de paso a producción, el alcance de la regresión por lanzamiento, las exclusiones conocidas y una frecuencia de revisión.
¿Cómo se planifica una estrategia de pruebas móviles?
Empieza por el coste, no por los dispositivos. Clasifica qué fallos (cierre inesperado al iniciar, fallo en el pago, pérdida de datos, rechazo en la tienda) costarían más en tu aplicación concreta. Después asigna cada uno a la capa más barata que lo detecta, nombra a quién decide un lanzamiento dudoso y, solo entonces, construye la matriz de dispositivos en torno a esos riesgos clasificados.
¿Una matriz de dispositivos es lo mismo que una estrategia de pruebas?
No. Una matriz de dispositivos es uno de los resultados de una estrategia, el último. Los equipos que construyen primero la matriz acaban con una amplia cobertura de dispositivos que no refleja su riesgo real, porque la matriz se basó en la cuota de mercado en lugar del coste clasificado de los fallos.
¿Quién debe ser responsable de una estrategia de pruebas móviles, QA o producto?
Ninguno de los dos por separado. Clasificar el coste de los fallos es una decisión de producto y de negocio; asignar las capas es una decisión de QA e ingeniería. La estrategia funciona cuando un mismo documento recoge ambas, con un responsable designado para los momentos en que las dos partes no están de acuerdo.
¡Descubre cómo ayudamos a BeFamily a lanzar una aplicación que fue un éxito rotundo desde el primer día!
