Requisitos de pruebas de una app móvil: ¿qué debe verificar una pequeña empresa antes de lanzar?

Los requisitos de pruebas definen qué tiene que funcionar, dónde tiene que funcionar, cómo se medirán los resultados, quién los acepta y qué defectos impiden publicar. Una pequeña empresa necesita ese plan antes de desarrollar, para que la calidad cubra los flujos reales, los dispositivos, las APIs, la accesibilidad, la seguridad, el rendimiento, la recuperación y la propiedad operativa.

Esta guía se ocupa de los requisitos de pruebas. Complementa los materiales de Le Website sobre el documento de requisitos, la arquitectura del backend, los controles de seguridad, los roles del equipo y la preparación del lanzamiento, sin sustituir esas decisiones.

¿Qué deben incluir los requisitos de pruebas de una app móvil?

Deben definir los recorridos críticos, los criterios de aceptación, los dispositivos y sistemas operativos soportados, los datos de prueba, los entornos, el comportamiento de la API, la accesibilidad, la seguridad, el rendimiento, el trabajo sin conexión, la recuperación, la analítica, las puertas de publicación, la severidad de los defectos, la evidencia, los responsables y la reprueba. Cada requisito necesita una condición de aprobación medible y alguien que la apruebe.

Empiece por el proceso del negocio y por el documento de requisitos de la app. El catálogo de pruebas debe rastrear cada requisito importante hasta escenarios normales, de límite, de error, de recuperación y de permisos. Debe identificar la compilación y el entorno exactos que se probaron, porque un prototipo que pasa no demuestra que funcione la versión de producción.

Arme un inventario de pruebas basado en riesgo

Ordene los recorridos por daño al cliente, impacto en los ingresos, interrupción operativa, sensibilidad de los datos, frecuencia, reversibilidad y exposición regulatoria. Dé más cobertura a identidad, pagos, recuperación de cuenta, acciones privilegiadas, trabajo sin conexión, sincronización, exportaciones e integraciones. Los detalles estéticos de bajo riesgo pueden llevar una evidencia proporcional en vez de consumir todo el calendario.

Haga de la evidencia parte del requisito

Una casilla marcada como «probado» es evidencia débil. Registre la versión, el dispositivo, el sistema operativo, el entorno, el rol de la cuenta, el conjunto de datos, los pasos, el resultado esperado, el resultado real, la marca de tiempo, quién probó, los adjuntos, el defecto enlazado y el resultado de la reprueba. Ese registro hace reproducible la aceptación y evita que un resultado viejo apruebe una compilación que ya cambió.

¿Cómo definen los criterios de aceptación si algo pasa o no pasa?

Un criterio de aceptación debe indicar la condición de partida, el rol del usuario, la acción, el resultado esperado en la interfaz y en los datos, el tiempo o la tolerancia, el resultado prohibido y la evidencia requerida. Use lenguaje observable en lugar de «funciona correctamente». Incluya casos de límite, de fallo, de recuperación y de autorización, para que una demostración del camino feliz no pueda aprobar un flujo incompleto o inseguro.

Conecte requisitos, historias de usuario, criterios de aceptación y casos de prueba con identificadores estables. Cuando cambie el alcance, el equipo verá qué pruebas deben cambiar y qué resultados anteriores dejaron de ser válidos. Quien es dueño de la regla de negocio debe aprobar el comportamiento esperado antes de que desarrolladores y probadores codifiquen supuestos distintos.

Especifique las reglas de negocio con ejemplos

Defina impuestos, descuentos, horarios, permisos, validaciones, cálculos, transiciones de estado, notificaciones y aprobaciones con ejemplos concretos. Incluya los casos de mínimo, máximo, vacío, duplicado, vencido, interrumpido y no autorizado. Los ejemplos sacan a la luz la ambigüedad temprano, pero la regla de fondo debe quedar explícita para que la batería de pruebas no se limite a esos valores de muestra.

Defina la severidad de los defectos antes de probar

La severidad refleja el impacto en el usuario y en el negocio; la prioridad, el orden en que se atienden. Defina qué condiciones son críticas, altas, medias o bajas; quién puede bajarles el nivel o aceptarlas; qué controles temporales se exigen; y cuándo caducan las excepciones. Una fecha de lanzamiento no debería reclasificar en silencio como «cosmético» un defecto que pierde datos.

¿Qué dispositivos y sistemas operativos debe cubrir la matriz de pruebas?

Cubra los dispositivos y versiones que usan sus clientes objetivo, además de los tamaños de pantalla soportados, las categorías de memoria, las condiciones de red, los idiomas, el escalado de texto, los permisos y los ajustes de accesibilidad. Priorice según la analítica de producción y la evidencia real de compra. Declare con claridad dónde termina el soporte y vuelva a revisar la matriz cuando cambien las plataformas o el uso de su audiencia.

Google documenta las bases de las pruebas en Android, las pruebas locales, las instrumentadas y las pruebas en distintas configuraciones en su guía oficial de pruebas de Android. Apple describe XCTest y los flujos de prueba en Testing in Xcode. Use las herramientas de la plataforma, pero que las decisiones de soporte sigan siendo del negocio.

Separe la evidencia de emulador de la de dispositivo real

Los simuladores y emuladores son eficientes para la regresión frecuente, pero solo un dispositivo real expone el comportamiento de la cámara, la biometría, los sensores, las notificaciones, la memoria, la batería, la ejecución en segundo plano, la conectividad, el teclado y las particularidades de cada fabricante. Defina qué escenarios exigen equipos físicos y cuáles pueden usar entornos virtuales. Una granja de dispositivos en la nube no sustituye la verificación práctica dirigida.

Pruebe los cambios de estado, no solo la instalación limpia

Cubra la instalación, la actualización desde versiones soportadas, la actualización interrumpida, la migración, la restauración de un respaldo, el cambio de idioma, el texto más grande, un permiso revocado, las notificaciones desactivadas, la pérdida de conexión, el poco almacenamiento, el giro de pantalla y el borrado de cuenta. Los clientes que ya usaban la app viven transiciones de estado que una cuenta nueva y una instalación recién hecha jamás muestran.

¿Qué casos de prueba funcionales son imprescindibles?

Pruebe cada recorrido crítico con entradas válidas, inválidas, duplicadas, interrumpidas, vencidas, no autorizadas y en el límite. Verifique la navegación, los cálculos, las transiciones de estado, las notificaciones, la búsqueda, los formularios, las cargas de archivos, los pagos, la recuperación de cuenta, los permisos y la analítica cuando aplique. Confirme tanto el resultado que ve el usuario como el estado autorizado en el servidor después de cada acción importante.

• Recorra el alta, el inicio de sesión, la recuperación, el cierre de sesión y los cambios de rol.
• Ejercite los flujos de crear, leer, modificar, eliminar, aprobar y revertir.
• Repita envíos y reintentos para detectar transacciones duplicadas.
• Interrumpa el trabajo con segundo plano, llamadas, giro de pantalla, bloqueo y pérdida de conexión.
• Verifique notificaciones, enlaces profundos, exportaciones, cargas y traspasos a terceros.
• Confirme que los eventos de analítica no se disparan dos veces ni exponen valores sensibles.

Pruebe transiciones y reversiones

Un flujo es más que pantallas sueltas. Verifique las transiciones permitidas y las prohibidas, las ediciones simultáneas, las cancelaciones, las devoluciones, las reasignaciones, las reaperturas, la finalización parcial y la reversión. Confirme que las etiquetas de la interfaz, los registros del servidor, las notificaciones, los reportes y las integraciones coinciden después de cada transición. Un estado contradictorio suele hacer más daño que un error visible.

Trate la analítica como un requisito de producto

Para cada evento importante defina el disparador, el nombre, los campos permitidos, las reglas de identidad, la deduplicación, el comportamiento del consentimiento, el entorno y el método de validación. Pruebe el éxito, el fallo, el abandono, el reintento y el envío diferido sin conexión. Una analítica que cuenta una vista de pantalla como una compra puede desviar decisiones de producto aunque la app parezca funcionar.

¿Cómo se prueban las APIs, los datos y las integraciones?

Pruebe los contratos de la API, la autenticación, la autorización, la validación, la idempotencia, la paginación, los límites de uso, los tiempos de espera, los reintentos, el orden de los mensajes, la compatibilidad entre versiones, el aislamiento entre organizaciones y las respuestas de error. Concilie los registros de la app, el servidor y los terceros tras el éxito y tras el fallo. Use datos de prueba controlados y verifique que un mensaje demorado o repetido no pueda corromper el estado del negocio.

La guía de requisitos del backend explica los límites entre servicios, la propiedad de los datos, la observabilidad, la fiabilidad y el despliegue. Los requisitos de pruebas deben convertir esas decisiones de arquitectura en pruebas de contrato, pruebas negativas de autorización, verificación de migraciones, comprobación del monitoreo y simulacros de recuperación.

Use pruebas de contrato cuando aporten

Registre la petición, la respuesta, los campos, los tipos, el comportamiento opcional, los códigos de estado, el modelo de error y la promesa de compatibilidad que necesita la app. Ejecute esas expectativas antes de que un cambio del servidor llegue a producción. Las pruebas de contrato detectan rápido las desviaciones de la interfaz, mientras que las pruebas de extremo a extremo confirman que la infraestructura real, la identidad y las reglas del negocio siguen funcionando juntas.

Diseñe pruebas seguras de fallo de terceros

Simule que los proveedores de pagos, mapas, mensajería, identidad, CRM, almacenamiento y analítica se ponen lentos, dejan de responder, duplican mensajes o entregan datos inconsistentes. Defina qué se le dice al usuario, los límites de reintento, las colas, la conciliación, las alertas y la recuperación manual. La caída de una dependencia no debe perder trabajo en silencio, ni exponer datos de otro cliente, ni generar cobros duplicados sin fin.

¿Qué requisitos de rendimiento y fiabilidad hay que probar?

Defina umbrales medibles para el arranque, la respuesta de pantalla, la latencia de la API, las cargas de archivos, la sincronización, la batería, la memoria, los cierres inesperados, los bloqueos, el consumo de red, la concurrencia y la recuperación, en condiciones representativas. Pruebe con redes lentas e inestables, con la app en segundo plano, con pocos recursos, con muchos datos y con servicios degradados. Ate los umbrales a los recorridos críticos y a los indicadores que vigila en producción.

La velocidad promedio esconde fallos graves. Registre percentiles, tasa de error, sesiones sin cierres inesperados, tiempos de espera agotados, profundidad de las colas, volumen de reintentos y tasa de finalización por grupos representativos. Una mediana rápida no protege a los clientes cuyos dispositivos antiguos, redes rurales, cuentas enormes o ajustes de accesibilidad hacen fallar el trabajo crítico.

Use volúmenes de datos realistas

Pruebe con cuentas que tengan el máximo esperado de registros, fotos, mensajes, trabajos, productos e historial. Verifique la paginación, la búsqueda, el caché, la sincronización y la memoria. Una cuenta nueva con diez registros no puede demostrar que un cliente con años de datos operativos vaya a tener una experiencia aceptable.

Pruebe la recuperación, no solo la detección del fallo

Interrumpa cargas, envíos, autenticaciones, sincronizaciones y tareas en segundo plano. Restablezca la conexión o el servicio y confirme que la app retoma con seguridad, preserva la intención del usuario, evita duplicados y explica qué quedó pendiente. Mida el tiempo de recuperación y deje evidencia. Un fallo detectado sigue siendo un problema de negocio cuando nadie puede restaurar el estado correcto.

¿Cómo se especifican las pruebas de accesibilidad y de usabilidad?

Exija que los recorridos críticos funcionen con lector de pantalla, con teclado o conmutador cuando aplique, con escalado de texto, zoom, contraste, orientación, movimiento reducido y con etiquetas y errores claros. Combine comprobaciones automáticas con pruebas hechas por personas. Defina qué estándares aplican, en qué plataformas, con qué reglas de severidad, qué evidencia, qué corrección y quién acepta, incluyendo a usuarios con esas necesidades.

Las Pautas de Accesibilidad para el Contenido Web 2.2 del W3C ofrecen criterios verificables, muchos de los cuales orientan también a las interfaces móviles y al contenido web incrustado. La guía de accesibilidad de cada plataforma y las pruebas con tecnología de apoyo real siguen siendo necesarias, porque un análisis técnico no puede juzgar si una tarea completa se entiende y se resuelve con eficiencia.

Pruebe recorridos completos con tecnología de apoyo

Verifique el alta, la autenticación, la recuperación, la búsqueda, el llenado de formularios, la confirmación, el soporte y el cierre de sesión con el lector de pantalla y los métodos de entrada correspondientes. Revise el orden de foco, los nombres, los roles, los valores, los anuncios, el tamaño de las zonas táctiles, los límites de tiempo, los errores y las actualizaciones dinámicas. Que cada control pase por separado no garantiza una experiencia utilizable de principio a fin.

Separe un hallazgo de usabilidad de una preferencia

Defina participantes, tareas, medidas de éxito, método de observación y reglas de decisión. Mida finalización, errores, tiempo, abandono, ayuda necesaria y comprensión. La preferencia estética de un directivo no equivale a la evidencia de que los usuarios objetivo no encuentran, no entienden o no completan una tarea crítica. Registre ambas cosas sin confundir su autoridad.

¿Cómo encajan la seguridad y la privacidad en el plan de pruebas?

Integre pruebas basadas en amenazas sobre identidad, autorización, almacenamiento local, comunicación de red, APIs, permisos, dependencias, privacidad, registros y controles de publicación. Defina alcance, severidad, corrección, reprueba y aceptación del riesgo. Las pruebas de seguridad deben cubrir la versión candidata y el backend, mientras que las de privacidad verifican la recopilación, el consentimiento, la retención, el borrado y el comportamiento de los proveedores.

Use la guía de requisitos de seguridad para definir los controles antes de elegir la profundidad de las pruebas. La guía de pruebas de seguridad móvil de OWASP aporta técnicas y casos específicos que respaldan una verificación con evidencia.

Pruebe las rutas negativas de autorización

Intente acciones sin identidad, con sesiones vencidas o revocadas, con roles inferiores, cambiando identificadores de objeto, desde otra organización, repitiendo peticiones, alterando el estado del cliente y llamando directamente a la API. Verifique que el servidor lo impide y que queda registro de auditoría. Un botón oculto en la interfaz no demuestra que la acción protegida sea inaccesible.

Revise los datos más allá de la base principal

Compruebe registros, analítica, reportes de fallos, notificaciones, respaldos, capturas, portapapeles, exportaciones, cachés, herramientas de soporte y el tráfico de los SDK de terceros. Pruebe la retirada del consentimiento, el borrado de cuenta y el comportamiento de la retención. La información sensible suele escaparse por canales operativos aunque la base principal y la conexión estén bien protegidas.

¿Cómo se equilibran las pruebas automáticas y las manuales?

Automatice lo estable y repetible: pruebas unitarias, de contrato, de integración, la regresión crítica, los análisis de accesibilidad y la verificación de compilación. Reserve lo manual para la exploración, la usabilidad, el comportamiento visual, la interacción con el dispositivo, los riesgos emergentes y los flujos ambiguos. Elija la cobertura por riesgo y por valor de mantenimiento, no por maximizar el número de pruebas ni el porcentaje de automatización.

Una batería por capas debe dar retroalimentación rápida cerca del código y conservar un conjunto más pequeño de pruebas de extremo a extremo confiables para las rutas críticas. La automatización inestable consume atención y destruye la confianza. Siga la causa de los fallos, el tiempo de ejecución, el esfuerzo de mantenimiento, los defectos que se escaparon y la cobertura de los flujos críticos, en vez de celebrar la cantidad de scripts.

Exija entornos de prueba deterministas

Versione datos de prueba, servicios, banderas de funcionalidad, cuentas, configuraciones, dispositivos y compilaciones. Proteja la información de producción y aísle las organizaciones. Cuando una prueba falla, el equipo debe poder distinguir un defecto del producto de una credencial vencida, un proveedor caído, datos de prueba obsoletos o una desviación del entorno. Un entorno descontrolado convierte los resultados en conjeturas.

Conserve las pruebas exploratorias

Dé a los probadores con experiencia una misión clara, un tiempo acotado, un foco de riesgo, un conjunto de datos y un formato de notas, sin encerrarlos en pasos guionados. La exploración revela combinaciones de estado inesperadas y comportamientos confusos. Registre cobertura, observaciones, evidencia, defectos y preguntas sin responder, para que el aprendizaje sea reutilizable y no quede en la memoria de una persona.

¿Cómo funcionan la aceptación del usuario y la aprobación para publicar?

Las pruebas de aceptación deben hacerse con roles, datos y dispositivos representativos, sobre flujos de negocio completos y en un entorno controlado con la versión candidata. Quien es dueño del proceso verifica los resultados, no la implementación técnica. La aprobación para publicar debe exigir que no queden bloqueos, con excepciones documentadas, evidencia de reprueba, identidad del artefacto, preparación operativa, propiedad de las cuentas de tienda, monitoreo, soporte y decisión de reversión.

TestFlight de Apple y los canales de prueba de Google Play sirven para distribuir compilaciones controladas, pero distribuir no es aceptar. La lista de verificación para lanzar una app móvil conecta los resultados de las pruebas con las declaraciones de privacidad, la analítica, el soporte, la propiedad de las cuentas, el despliegue, el monitoreo y la respuesta posterior.

Use escenarios de aceptación del propio negocio

Pida a los responsables reales de cada proceso que verifiquen pedidos, citas, aprobaciones, trabajo en campo, atención al cliente, reportes y excepciones con datos realistas. Los desarrolladores pueden apoyar el diagnóstico, pero no deberían aprobar solos el resultado de negocio. Registre quién aceptó cada escenario crítico y qué limitaciones quedan a la vista de quienes deciden.

Ate la aprobación al artefacto exacto

Registre versión, número de compilación, commit de origen, entorno, configuración, conjunto de dependencias, identidad de firma, resultados de prueba, aprobadores, problemas conocidos y envío a la tienda. Vuelva a ejecutar las puertas necesarias tras cualquier cambio relevante. Aprobar la compilación 105 no aprueba automáticamente la 106 porque la diferencia parezca pequeña.

Preguntas frecuentes sobre los requisitos de pruebas de una app móvil

Las dudas más comunes son cuándo empezar a probar, qué dispositivos importan, si basta con la automatización, quién debe hacer la aceptación y qué evidencia debe entregar el proveedor. La respuesta práctica es definir la cobertura por riesgo antes de programar, probar de forma continua, conservar evidencia reproducible y dar a personas con nombre la autoridad sobre la decisión de publicar.

¿Cuándo hay que empezar a probar?

Las pruebas empiezan cuando se escriben los requisitos. El equipo debe revisar criterios de aceptación, riesgos, datos, arquitectura y verificabilidad antes de programar; añadir pruebas unitarias, de integración y de contrato durante el desarrollo; probar compilaciones completas de forma continua; y reservar la aceptación del usuario, la versión candidata, la revisión de tiendas y la verificación operativa para versiones ya estables.

¿Cuántos dispositivos debe probar una pequeña empresa?

No hay un número universal. Elija una matriz que cubra la analítica de sus usuarios o la evidencia del mercado, los sistemas operativos soportados, las diferencias relevantes de pantalla y hardware, los ajustes de accesibilidad y las funciones de mayor riesgo. Combine un grupo pequeño de dispositivos físicos con cobertura virtual o en la nube, y publique dónde termina el soporte.

¿Las pruebas automáticas pueden sustituir a las manuales?

No. La automatización comprueba con eficiencia las reglas estables y la regresión, pero no sustituye el criterio exploratorio, la observación de la usabilidad, la interacción con un dispositivo real, la experiencia de accesibilidad ni la investigación de estados inesperados. Un buen plan asigna cada riesgo al método más barato capaz de producir evidencia creíble y repetible.

¿Quién debe hacer las pruebas de aceptación?

Los responsables de los procesos de negocio y los roles de usuario autorizados deben ejecutarlas o aprobarlas. Los desarrolladores y los especialistas de calidad preparan entornos, casos y evidencia, pero quienes responden por la operación son los que deciden si los flujos, las reglas, los reportes, las excepciones y los traspasos cubren las necesidades reales de la organización.

¿Qué evidencia de pruebas debe entregar el proveedor?

El traspaso debe incluir la estrategia de pruebas, el mapa de trazabilidad, la matriz de dispositivos, los entornos, los casos, los resultados, el registro de defectos, la evidencia de reprueba, las baterías automatizadas, los límites de cobertura, los hallazgos de accesibilidad y seguridad, los riesgos aceptados, el registro de la publicación, los problemas conocidos, las comprobaciones de monitoreo, los procedimientos de recuperación, las cuentas y las instrucciones para repetir la verificación crítica.

¿Cuál es el siguiente paso?

Empiece por los cinco recorridos de mayor impacto, el límite de dispositivos soportados, el mapa de backend e integraciones, los umbrales críticos de calidad y quién tiene la autoridad para publicar. Convierta cada recorrido en pruebas normales, de límite, de fallo, de recuperación, de accesibilidad y de autorización. Si Le Website planifica el proyecto, conectamos el alcance de las pruebas con los requisitos, la arquitectura, la entrega y la propiedad.

Traiga sus flujos actuales, los roles de usuario, la evidencia de dispositivos, las clases de datos, las integraciones, las restricciones de cumplimiento, las necesidades de analítica y las propuestas que haya recibido. Escríbanos para convertir todo eso en requisitos verificables, un plan de calidad realista y un proceso de publicación que deje el control en manos del negocio.

Revisado el 24 de agosto de 2026. Este artículo ofrece orientación general de producto y de calidad; no constituye asesoría legal ni regulatoria, ni certificación de conformidad de accesibilidad o seguridad para una aplicación concreta.