Los testers pierden su primera sesión cuando el backend está caído, la cuenta de prueba no funciona o la app apunta al servidor equivocado. Ejecuta esta lista antes de enviar cualquier invitación. Cada punto tiene un motivo y una forma de verificarlo.
| # | Punto | Por qué | Cómo comprobarlo |
|---|---|---|---|
| 1 | La compilación apunta al backend de prueba, no a producción | Las acciones de prueba no deben tocar a usuarios ni dinero reales | Revisa la URL base en la compilación instalada; haz una acción y búscala en la base de datos de prueba |
| 2 | El backend de prueba está activo y accesible desde fuera de tu red | Los testers no están en tu Wi-Fi ni en tu VPN | Ábrelo desde datos móviles en un teléfono |
| 3 | Existen cuentas de prueba para cada rol (usuario nuevo, habitual, admin si aplica) | Los testers no deben perder tiempo registrándose o adivinando | Inicia sesión con cada una desde una instalación limpia |
| 4 | Las credenciales están en la invitación, no solo en tu cabeza | Evita la primera pregunta de soporte | Relee la invitación como si fueras un desconocido |
| 5 | Los datos de ejemplo son realistas (nombres largos, listas vacías y llenas, caracteres especiales) | Los datos vacíos u ordenados ocultan errores de diseño y de lógica | Recorre las listas principales con estos datos |
| 6 | Los datos se pueden restablecer rápido | Tras una mala sesión de pruebas necesitas un estado limpio | Ejecuta tu reinicio una vez y cronométralo |
| 7 | Los pagos y correos funcionan en modo sandbox o de prueba | Sin cargos reales ni correos a direcciones reales | Haz una compra de prueba; comprueba a dónde van los correos |
| 8 | Los feature flags están configurados para la compilación que se prueba | Las funciones sin terminar deben ocultarse o marcarse | Lista los flags y sus valores para esta compilación |
| 9 | Las claves de terceros (mapas, push, autenticación) son válidas para la compilación de prueba | Las claves ligadas a otro ID de app fallan en silencio | Activa cada servicio una vez en un dispositivo |
| 10 | Las notificaciones push llegan a un dispositivo de prueba | A menudo solo fallan en las compilaciones de prueba | Envía una desde el backend |
| 11 | El reporte de fallos y errores está activo, con el número de compilación adjunto | Si no, no recibirás logs de los testers | Provoca un fallo de prueba y encuéntralo en el panel |
| 12 | El registro (logging) no guarda contraseñas ni datos personales | Los datos de prueba pueden ser datos reales de personas | Lee una muestra de líneas del log |
| 13 | Los testers pueden instalar la compilación (enlace, grupo o invitación funciona) | El primer fallo más habitual | Instala por la ruta exacta que usarán los testers, en un segundo dispositivo |
| 14 | El número de compilación es visible en la app | Cada informe necesita una versión | Abre los ajustes o una pantalla "Acerca de" |
| 15 | Existe una lista de problemas conocidos | Evita que los testers informen de lo que ya sabes | Escríbela antes de la invitación |
| 16 | Hay un único lugar para enviar feedback y lo vas a ver | El feedback disperso se pierde | Envíate a ti mismo un informe de prueba |
Plantilla: nota de preparación previa a la invitación
Entorno: [URL de staging] Compilación: [número] Fecha: [fecha]
Revisado por: [nombre]
[ ] 1-16 de arriba hechos. Excepciones: [lista]
Problemas conocidos: [lista]
Procedimiento de reinicio: [pasos]
Adáptala
Quita los puntos que no apliquen (sin backend, sin pagos). Añade lo específico de tu stack, como una migración de base de datos o un modo demo con datos cargados. Para saber cómo probar migraciones, mira las comprobaciones relacionadas en probar migraciones de base de datos sin perder datos.
Relacionado
- Índice: índice de checklists de pruebas de apps móviles
- Checklist de política de privacidad para apps móviles
- Checklist previa al lanzamiento: 30 cosas que verificar
Cuando el entorno esté listo, AppReviewX puede aportar feedback privado y estructurado de testers. Un feedback = 1 crédito; las cuentas nuevas empiezan con 0. Empieza gratis.