Por qué fallan las pruebas cerradas: notas de campo de la ventana de 14 días
La mayoría de las solicitudes de acceso a producción no se pierden en el formulario. Se pierden en algún punto intermedio de la ventana, cuando el recuento se desliza por debajo del mínimo sin que nadie se dé cuenta hasta que Google lo devuelve.
El requisito es fácil de enunciar: 12 testers, unidos y probando de forma continua durante 14 días. Las cuentas personales creadas después del 13 de noviembre de 2023 no pueden distribuir una app hasta que esa ronda esté completa y la solicitud haya sido revisada.
Los desarrolladores lo interpretan como un problema de reclutamiento, así que todo el esfuerzo va al primer día. El chat grupal, el servidor de Discord, los primos. El resto de la ventana se trata como un período de espera. En ese planteamiento es donde mueren las pruebas. El requisito no son doce testers el primer día. Son doce testers cada día de la ventana, también los días en que nadie está pensando en tu app.
Las tres formas en que muere una prueba
1. El recuento se desliza
Las adhesiones llegan al principio. Casi todos los que vayas a tener dicen sí en los primeros días, cuando aún estás pidiendo. La fuga va en la dirección contraria, despacio, durante dos semanas: un tester se da de baja, desinstala al limpiar el móvil, pierde el interés. Cada salida es pequeña. El umbral, no. Con once estás por debajo del mínimo y la ronda deja de contar.
Los días tampoco vuelven. La orientación de Google es explícita: el periodo tiene que ser consecutivo. Un tester que se da de baja y vuelve a unirse más tarde empieza una racha nueva, no una reanudada. Un bache que dejas pasar el sexto día puede costarte toda la ventana.
2. La instalación que nunca se abre
El recuento no es todo el requisito. Google lista el compromiso insuficiente de los testers como motivo declarado para devolver una app a pruebas continuas, justo al lado de caer por debajo del mínimo. El número puede ser correcto y la solicitud vuelve igualmente.
Este es el fallo que mejor se esconde. Un enlace de adhesión pone un nombre en la lista; no pone una sesión en tus analíticas. Los testers que instalan y nunca abren la app mantienen el panel en verde mientras la señal real se deteriora debajo. Nada se pone en rojo.
También te alcanza en el formulario. La solicitud pregunta qué hicieron los testers: si usaron todas las funciones disponibles, si su uso coincidía con el comportamiento en producción, qué feedback recibiste y cómo lo recogiste. Una prueba sin actividad no tiene respuesta para esas preguntas, y una respuesta en blanco no es neutral.
3. La cuenta ya estaba en problemas
Algunas rondas se pierden antes de empezar. Una solicitud de acceso a producción anterior que fue rechazada. Un listado de la tienda incompleto. Un problema de políticas nunca resuelto. Los catorce días corren, los informes llegan, el formulario sale y Google rechaza por una razón que no tiene nada que ver con tus testers. Revisa la cuenta antes de arrancar el reloj, no después de que vuelva.
Por qué la obsesión por reclutar al principio es la equivocada
La regla de adhesión continua cambia la cuenta. Los testers no valen lo mismo cada día de la ventana.
Perder tu décimo segundo tester el día doce cuesta más que ganar cinco testers el día cero. Los reclutas tempranos son baratos y abundantes: el enlace de adhesión admite hasta 100 nombres, así que el techo nunca fue el limitante. Los testers de la parte final de la ventana son los que sostienen la ronda.
Así que el número que hay que optimizar no es el pico de participantes. Es el mínimo en el peor día. Recluta con un margen holgado por encima del mínimo y luego dedica las dos semanas siguientes a defender el mínimo.
Cómo se ve realmente la caída
Una prueba que falla tiene una forma, y se ve en el recuento diario:
- Días 1 al 3. El recuento salta a su pico. Todos los que invitaste aparecen. Esto se siente como éxito y es la parte menos informativa de la gráfica.
- Días 4 al 9. La etapa tranquila. Uno o dos testers se desvanecen, el recuento sigue por encima del mínimo, así que nada se ve mal. Aquí es donde las rondas empiezan a torcerse, y es la parte que la gente deja de revisar.
- Días 10 al 14. Donde las rondas se pierden de verdad. El recuento lleva una semana erosionándose, el desarrollador no abre la consola desde hace tres días, y una sola salida ahora lo reinicia todo.
La revisión diaria es aburrida: abre la consola y compara hoy con ayer. Veinte testers cayendo hacia doce es una peor posición que catorce mantenidos estables.
Cómo se ve una prueba sana
Tres cosas, en orden:
- La tendencia. La dirección te dice cómo será la próxima semana. El total solo te dice dónde estás hoy.
- Si los testers abren la app. Las adhesiones son el requisito; las sesiones son para lo que sirve el requisito. Si no ves actividad, estás llevando una lista, no una prueba.
- La fecha en la que reiniciarías. Mantenla visible los catorce días. Cada día que el recuento aguanta, esa fecha se aleja, y es el único marcador que importa.
Cuando el número caiga, reemplaza al tester ese mismo día, desde una fuente en la que ya confías. Un bache que reparas en veinticuatro horas no te cuesta nada. Un bache que reparas el día trece cuesta dos semanas. Esperar a ver si vuelven es la opción más cara.
La etapa que nadie puede falsear
Mantener el recuento lleva unos minutos al día. Lo difícil es el suministro: testers verificados que sigan unidos durante toda la ventana, no gente que instala el día dos y desaparece.
Esa es la parte que lleva Console Testers. Ponemos 30 testers verificados en tu grupo de pruebas y los mantenemos ahí durante toda la ventana y más allá, con los informes de prueba generados al final para el formulario de acceso a producción. El recuento no depende de que tu chat grupal siga vivo el día once.
El fondo honesto
El reclutamiento pasa el primer día. La prueba pasa en los otros trece días, y esos son los que nunca aparecen en el calendario.
Atención diaria durante catorce días te lleva al formulario. Un rechazo te devuelve con catorce días más antes de poder llenarlo de nuevo.
Fuentes
- Ayuda de Google Play Console: requisitos de prueba de apps para cuentas personales de desarrollador nuevas, para el mínimo de testers, la regla de adhesión continua, el compromiso como motivo de pruebas continuas, el formulario de solicitud y el momento de la revisión.