En esta guía
Son convenciones, no reglas: los equipos usan las palabras de forma distinta. La tabla muestra una lectura común. Los tracks de la tienda (interno, cerrado, abierto) son un concepto aparte; mira prueba cerrada vs despliegue por fases vs soft launch.
Las etapas
| Alfa | Beta | Release candidate | |
|---|---|---|---|
| Objetivo | ¿Hace al menos lo básico? | ¿Funciona para personas distintas de ti? | ¿Está esta versión lista para publicarse tal cual? |
| Completitud | Las funciones pueden faltar o estar toscas | Completa o casi | Completa; solo correcciones bloqueantes |
| Quién prueba | Tú, tu equipo, unas pocas personas de confianza | Testers externos que se parezcan a tus usuarios | Los mismos testers, más una revisión final tuya |
| Feedback que quieres | Crashes, flujos rotos | Usabilidad, problemas de dispositivo, partes confusas | Solo bloqueantes graves |
| Cambios permitidos | Cualquiera | Correcciones y pulido; funciones rara vez | Solo correcciones bloqueantes |
| Condición de salida | Los flujos básicos funcionan | Sin problemas conocidos importantes | Sin bloqueantes; la publicarías |
Uso práctico
- No te saltes el medio. Pasar de tus propias pruebas directo al lanzamiento hace que los usuarios reales encuentren los problemas.
- Congela el alcance en el RC. Si añades funciones, vuelve a ser beta.
- Escribe las condiciones de salida antes de cada etapa. Sin ellas, las etapas nunca terminan.
- Asigna testers a la etapa. Alfa: gente que tolera los bordes rústicos. Beta: gente como tus usuarios. RC: quien note cualquier regresión.
Dónde encaja AppReviewX
Sobre todo en la etapa beta, para apps ya publicadas en una tienda: otros desarrolladores dan feedback privado y estructurado (1 feedback aceptado = 1 crédito; cuentas nuevas con 0). No se distribuyen builds ni instaladores.
Relacionado: todas las opciones de prueba, beta test vs soft launch, prueba cerrada vs despliegue por fases vs soft launch.