No: nunca se reinicia
Una actualización normal mantiene corriendo el tiempo de participación de tus testersGoogle no publica ninguna regla que diga que crear una versión nueva reinicia la prueba cerrada. El requisito trata de que cada tester siga con la participación aceptada durante 14 días de forma continua, con al menos 12 testers así cuando haces la solicitud. Tu versionCode y el número de builds que subes no forman parte de él.
Que los testers salgan de la prueba y queden menos de 12 con 14 días sin interrupción.
Un tester que deja de participar y vuelve a unirse empieza de nuevo sus propios 14 días, y un reemplazo empieza desde el día uno. Si eso te deja con menos de 12 testers con 14 días sin interrupción, tu solicitud tiene que esperar. La causa no es la actualización.
Respuesta rápida
No. Actualizar la misma app en su canal de prueba cerrada (closed testing) en curso no reinicia por sí solo el tiempo de participación de tus testers. Para cuentas personales de desarrollador creadas después del 13 de noviembre de 2023, la app necesita al menos 12 testers que hayan seguido cada uno con la participación aceptada durante los últimos 14 días consecutivos cuando solicitas acceso a producción. Un tester que deja de participar empieza de nuevo sus propios 14 días. Google recomienda actuar según los comentarios, pero no publica un número obligatorio de versiones. Si los testers no ven un build nuevo, revisa la publicación, quién puede recibir el lanzamiento y la actualización en el dispositivo.
Es uno de los miedos más comunes de la prueba cerrada: vas a mitad de tu ventana de 14 días, detectas un bug y te congelas, con miedo de que subir el arreglo borre tu progreso y te obligue a empezar las dos semanas de nuevo. No lo hará. El requisito de 14 días mira a tus testers, no a tus builds. Esta guía separa qué interrumpe la ventana de la prueba cerrada de qué no, te da dos herramientas interactivas para probar cualquier acción tú mismo y explica qué revisar cuando los testers no ven un build nuevo. Se comprobó por última vez contra las páginas de ayuda de Google el 16 de octubre de 2026.
En esta guía
¿Actualizar mi app reinicia el reloj de 14 días de la prueba cerrada?
No. Es el miedo más común entre desarrolladores en su ventana de pruebas, y la respuesta tranquiliza: subir un app bundle nuevo a tu canal de prueba cerrada existente no reinicia por sí solo el tiempo de participación de tus testers.
El requisito de 14 días está atado a tus testers, no a tu build. Google lo mide por tester: cuando solicitas acceso a producción, al menos 12 testers deben haber aceptado participar cada uno durante los últimos 14 días de forma continua. El número de versión de tu app, cuántas veces subes un AAB nuevo y qué cambias en las notas de la versión no forman parte de ese requisito.
Esta misma pregunta aparece una y otra vez en la comunidad de desarrolladores de Google Play. La ayuda de Play Console de Google define el requisito solo en términos de testers con participación aceptada y tiempo, nunca en términos de subidas de builds. Un Product Expert de Google dio la respuesta práctica de forma directa en una respuesta aceptada de la comunidad en enero de 2024: una actualización durante las pruebas puede necesitar una revisión, pero no reinicia los 14 días. Es la lectura de un experto sobre la política, no una frase de la propia política.
¿Dudas de una acción concreta? Usa el verificador de abajo: elige lo que estás a punto de hacer y te dice si afecta a los 14 días de tus testers.
¿Qué acción te preocupa?
Basado en el requisito publicado de Play Console de Google (testers con participación aceptada × días de forma continua) más experiencia amplía de desarrolladores. Los dos riesgos señalados por la comunidad están marcados como tales.
¿Qué reinicia de verdad el timer de 14 días?
La ventana de 14 días de forma continua se entiende mejor como un control de consistencia, no como una cuenta atrás pasiva del calendario. Google quiere ver que mantuviste al menos 12 testers con participación aceptada sin interrupción. Solo hay dos disparadores confirmados que rompen esa continuidad:
El conteo con participación aceptada baja de 12
Si un tester se va y te quedas con 11 testers que cuentan, no puedes solicitar hasta que un duodécimo tester tenga 14 días sin interrupción, y un reemplazo empieza desde el día uno. Por eso ir con exactamente 12 es arriesgado.
Los testers dejan de participar de forma formal
Un tester deja de participar abriendo el enlace web de la prueba y eligiendo salir. Eso es distinto de desinstalar. Los 14 días propios de ese tester se detienen, y volver a unirse los empieza de nuevo. Solo retrasa tu solicitud si te deja con menos de 12 testers que cuentan.
Subir un build nuevo no está en esa lista. Tampoco corregir un typo en la ficha, que un tester envíe feedback ni que tu app crashee en el dispositivo de un tester: eso último es justo el punto del testing. El simulador de abajo deja la diferencia en claro: pulsa el botón de update y no se mueve nada, pero si pierdes testers y bajas de 12 la racha se derrumba.
Qué NO reinicia el reloj
Subir un AAB nuevo al mismo canal
Editar notas de release o ficha de la tienda
Que un tester envíe feedback
Que tu app crashee en el dispositivo de un tester
Subir el versionCode o el nombre de versión
Que un tester desinstale sin dejar de participar
¿Cómo envío una actualización a una prueba cerrada?
Enviar un update es el mismo flujo que tu primer release, con una diferencia importante: creas el release nuevo en el mismo segmento de prueba cerrada en el que tus testers ya aceptaron participar. No estás empezando una prueba nueva: estás sumando un build a la prueba que ya corre, y por eso el reloj de 14 días sigue ticando. Estos son los dos pasos en Play Console.
Crea una versión nueva en tu canal cerrado Test and release > Testing > Closed testing > Manage track
Abre el canal de prueba cerrada (segmento de pruebas, en la documentación de Google para Latinoamérica) que ya tenías en marcha, haz clic en Create new release y sube tu app bundle actualizado (AAB). Mantén el mismo nombre de paquete y la misma configuración de firma, y dale al build un versionCode más alto: cambiar solo el versionName no es una actualización. Agrega notas de la versión cortas describiendo qué cambió y guarda. Quédate en el mismo canal: eso es lo que mantiene corriendo los 14 días de tus testers.
Revisa y lanza el update Review release > Start roll-out
Avanza con Next y Review release, y luego inicia el lanzamiento en tu canal cerrado. Después abre Publishing overview: si hay cambios esperando, elige Send changes for review, y si la publicación gestionada está activada, publica tú mismo los cambios aprobados. Una actualización enviada puede aparecer como In review antes de que la reciban los testers, y Google indica que un cambio publicado puede tardar varias horas en llegar a los testers. Los testers actuales normalmente se actualizan sobre la instalación existente, sin reinstalar y sin aceptar participar de nuevo.
Esto no reinicia el tiempo de participación de tus testers. Como publicas en el mismo canal cerrado en el que tus testers ya aceptaron participar, sus 14 días siguen corriendo bajo el build nuevo. Estás sumando un build, no empezando una prueba nueva. Si los testers siguen sin ver el build nuevo, repasa las comprobaciones de la siguiente sección.
¿Por qué los testers no reciben el build nuevo?
Primero comprueba si el build previsto está publicado en el canal del tester, luego revisa la cuenta del tester y la versión instalada, y solo después el teléfono. Es un orden de comprobaciones, no una clasificación de las causas más comunes. Terminaste cuando un tester apto instaló el build previsto y volvió a probar el cambio; una fecha nueva en la ficha de Play Store no basta.
Mi actualización sigue en revisión
Una actualización enviada puede necesitar revisión antes de que ese build llegue a los testers. Abre Publishing overview en Play Console y actúa según lo que muestre:
- Changes not yet sent (cambios aún no enviados): revisa la lista y elige Send changes for review.
- In review (en revisión): confirma que es la app, el canal y la versión correctos, y sigue cualquier mensaje de la Console. No subas otro build solo para refrescarla; Google cuenta el tiempo de revisión desde el último cambio enviado.
- Changes ready to publish (cambios listos para publicar): la publicación gestionada está activada, así que publica tú mismo los cambios aprobados.
Una versión que espera revisión y tus testers que siguen con la participación aceptada son estados distintos. Google no documenta que la revisión de una actualización normal pause ni reinicie el tiempo de participación de tus testers.
Solo algunos testers pueden actualizar
Una actualización publicada solo llega a los testers a los que se despliega y que cumplen los requisitos para recibirla. Revisa esto en orden:
- Lanzamiento gradual: las actualizaciones en los canales de pruebas, incluida la prueba cerrada, pueden usar un porcentaje de lanzamiento, y ese porcentaje no sube solo. En Closed testing > Releases, abre Manage rollout para ver el porcentaje y si el lanzamiento está detenido.
- Cuenta: la dirección de tu lista o de tu Google Group, la cuenta que aceptó participar y la cuenta con la sesión iniciada en Play Store deben ser la misma.
- Pruebas internas: un tester que sigue con la participación aceptada en tu prueba interna no puede recibir los builds de la prueba cerrada hasta que salga de la prueba interna y se una a la cerrada. Es una reparación de la inscripción, no un paso rutinario de actualización.
- Version code: Google Play instala el versionCode compatible más alto que le corresponde al tester. Cambiar solo el versionName no es una actualización.
- Dispositivo: el build debe ser compatible con el dispositivo del tester, y tu configuración de distribución debe incluirlo.
La versión está disponible, pero el teléfono sigue con el build antiguo
Usa la vía de actualización de la propia Play Store antes de tocar la inscripción del tester:
- Abre la ficha de la app en Play Store desde tu enlace de la prueba y toca Actualizar si aparece, o ve a tu perfil > Gestionar apps y dispositivo > Actualizaciones disponibles.
- Revisa la actualización automática: puede estar desactivada, limitada a Wi-Fi o desactivada solo para esta app.
- Revisa la conexión y el almacenamiento libre; luego cierra y vuelve a abrir Play Store.
- Solo entonces borra la caché de Play Store (información de la app > Almacenamiento y caché > Borrar caché). Borrar la caché no puede publicar una versión que sigue en revisión.
No pidas a los testers que salgan de la prueba y vuelvan a unirse para recibir una actualización. Salir rompe los 14 días sin interrupción de ese tester. Desinstalar la app, borrar los datos de los servicios de Google Play o restablecer el teléfono tampoco forma parte de una actualización normal.
¿Cuál es la diferencia entre testers invitados y con participación aceptada?
Esta distinción tropieza a más publicadores primerizos que cualquier otra, y es la clave para entender por qué los builds no importan al reloj. El sistema de Google mueve a los testers por un embudo, y solo las etapas posteriores pesan.
Invitado
Agregaste un correo a tu lista de testers o a un Google Group. Aún no pasó nada más.
Con participación aceptada
Hicieron clic en tu enlace de la prueba, iniciaron sesión con su cuenta de Google y eligieron Become a tester. Ese es el estado que mide el reloj de 14 días.
Instalado y activo
Descargaron la app y la siguen usando. Eso no cambia el conteo bruto, pero es lo que Google pesa para engagement al momento del acceso a producción.
Como deja claro la documentación de Google, agregar un correo no basta. Cada tester debe abrir el enlace de la prueba, autenticarse y aceptar participar de forma explícita antes de contar. Eso también explica por qué una actualización normal de la app no reinicia tu progreso: tus testers siguen con la participación aceptada, así que sus días siguen contando en cada build nuevo. Para el recorrido completo, consulta nuestra guía sobre cómo invitar testers de forma correcta.
Consejo de gestionar miles de pruebas: gestiona tus testers con un Google Group en lugar de una lista de correos estática. Google documenta que subir un CSV sobrescribe la lista de testers anterior, así que un Group evita borrar por accidente testers activos mientras la ajustas. Aun así, un Group no es una garantía: la membresía sigue controlando el acceso, así que quitar a alguien del Group o vincular otro Group cambia quién puede participar.
¿Cuál es la redacción exacta del requisito de Google?
La página oficial de ayuda de Play Console de Google, "App testing requirements for new personal developer accounts", lo dice con precisión:
"If you have a newly created personal developer account, you must run a closed test for your app with a minimum of 12 testers who have been opted-in for at least the last 14 days continuously."
Google Play Console Help · answer 14151465Y por separado, en el momento en que solicitas acceso a producción:
"At least 12 testers must be opted-in to your closed test when you apply for production access. They must have been opted-in for the last 14 days continuously."
Google Play Console Help · answer 14151465Google también deja en claro, con sus propias palabras, que los días deben ser consecutivos: no contará a testers que aceptaron participar, probaron menos de 14 días y luego dejaron de participar, y aunque vuelvan a aceptar, los 14 días consecutivos son los que cuentan. Esa sola cláusula mata por sí sola el mito de que "los 14 días son acumulativos" y, igual de importante, no dice nada sobre tus builds.
Tres hechos para fijar
¿Enviar actualizaciones durante el testing es bueno o malo?
Aquí la ansiedad del desarrollador se vuelve oportunidad. Enviar updates durante tu prueba cerrada se ve de forma amplia como una señal positiva de engagement. Conviene separar lo que Google dice de forma oficial de lo que concluyó la comunidad de desarrolladores, porque se solapan sin ser idénticos:
Sigue iterando y corrigiendo
La ayuda de Play Console fomenta la iteración continua: sigue usando la prueba cerrada mientras corriges problemas y bugs reportados por usuarios, y actualizar tu app en la prueba cerrada antes de ir a producción es "una gran forma de minimizar reseñas y valoraciones de baja calidad".
Cuando solicitas acceso a producción, el cuestionario te pide describir el engagement que recibiste y qué hiciste con el feedback de los testers.
Activo gana a congelado
Los profesionales van más lejos: una app congelada en la versión 1.0 durante 14 días sin ninguna actividad parece testing de marcar la casilla, mientras que una que publica correcciones en respuesta a los comentarios parece desarrollo genuino. Algunos desarrolladores publican dos o tres actualizaciones pequeñas para mostrar capacidad de respuesta, pero Google no publica ninguna cuota así (consulta la sección sobre el número de versiones más abajo).
Esto es opinión de la comunidad e inferencia razonable, no una regla publicada de Google. Google no fijó ningún requisito numérico de "publica X actualizaciones".
La conclusión: actualizar es seguro y se fomenta, y la historia de engagement que construyes con eso puede ayudarte a responder el cuestionario de acceso a producción. El único riesgo real viene de lo que envías, no del acto de enviar, y eso lleva a la única salvedad genuina.
¿Necesitas dos o tres versiones durante la prueba cerrada?
La guía publicada de Google sobre pruebas cerradas no fija un número mínimo de versiones. Recomienda actuar según los comentarios de los testers y corregir los problemas que encuentren las pruebas, y la solicitud de acceso a producción te pide describir los cambios que hiciste. Un recuento de subidas no forma parte del requisito.
- Mantén al menos 12 testers con participación aceptada durante 14 días sin interrupción (requisito publicado)
Protege desde el primer día la participación sin interrupción de cada tester. - Actúa según los comentarios y corrige los problemas que encuentren las pruebas (guía de Google)
Guarda un registro breve de los comentarios, la corrección y la nueva prueba. - Publicar dos o tres versiones pase lo que pase (mito de la comunidad, sin cuota publicada)
No fabriques cambios ni esperes que un número de versiones te consiga la aprobación.
De dónde viene el consejo: la versión explícita más antigua que encontramos es la suposición de un desarrollador, en una conversación de octubre de 2024, de que dos o tres actualizaciones podrían mostrarle a Google un trabajo guiado por los comentarios. Se repitió en hilos de la comunidad en pocas semanas y más tarde apareció en guías como si fuera una recomendación de Google. La fuente original es desconocida, y hay desarrolladores que reportan rechazos tanto con varias actualizaciones como sin ellas, así que un número de versiones no prueba nada por sí solo.
Si las pruebas encuentran un problema real, corrígelo, publica el build y pide a los testers que vuelvan a probar. Si no lo encuentran, dilo con honestidad cuando respondas el cuestionario de acceso a producción. Subir builds cosméticos mientras una actualización está en revisión también puede hacer retroceder tu app en la cola de revisión, porque Google cuenta el tiempo de revisión desde el último cambio enviado.
¿Puede un update malo reiniciar mi reloj de forma indirecta?
Sí, y esta es la única salvedad que importa. Aunque el acto de actualizar nunca reinicia el timer de forma directa, las consecuencias de un update roto sí pueden. Sigue la cadena:
Así que la regla es simple: actualiza con libertad, pero revisa la estabilidad base de cada build antes de enviarlo a tu segmento cerrado. Y nunca corras con exactamente 12 testers, porque un solo abandono por un build malo puede hundirte. Un colchón de testers por encima de 12 absorbe ese riesgo.
Lee la cadena con cuidado: la actualización no reinicia el tiempo de participación de nadie. El retraso viene de perder testers que cuentan; el build roto es solo lo que provocó los abandonos. Mantén tus builds estables y un colchón, y el riesgo indirecto se vuelve mucho menor.
¿Los testers necesitan reinstalar o aceptar participar de nuevo tras un update?
No. Los testers que ya aceptaron participar e instalaron tu app normalmente se actualizan sobre la instalación existente a través de Google Play. No necesitan volver a aceptar participar, y tú no necesitas reenviar el enlace.
Las actualizaciones normalmente se instalan sobre la versión existente
La ayuda de Play Console de Google, en Set up an open, closed, or internal test (answer 9845334), lo dice con claridad: "Once your testers have installed your app, they'll automatically be updated to use the test version within a few minutes." Los testers siguen con la participación aceptada en cada build: sin reinstalar, sin un segundo clic para aceptar participar.
Un matiz de timing de esa misma página de Google: cuando publicas cambios adicionales, "pueden no estar disponibles para los testers durante varias horas" antes de que arranque la actualización automática en el dispositivo. Pero el estado de participación aceptada de los testers, que es lo que mide el reloj de 14 días, se mantiene en cada AAB nuevo. Justo por eso una actualización de build no reinicia el reloj: los testers nunca se fueron.
Excepción importante Los permisos nuevos pueden interrumpir el update silencioso
Hay un tipo de build que no siempre se despliega en silencio: un update que agrega un permiso peligroso (sensible) nuevo como ACCESS_FINE_LOCATION, cámara o micrófono. Según el permiso y tu target API level, Google Play puede mostrar un botón Update que el tester tiene que tocar y aprobar a mano en lugar de instalarlo en segundo plano, y quien lo ignore se queda en el build viejo. Incluso cuando se instala en silencio, el permiso nuevo solo se concede en runtime, así que una función condicionada al permiso puede verse rota hasta que el tester lo permita.
En una prueba cerrada eso es una trampa silenciosa: publica a mitad de prueba una actualización cargada de permisos y algunos testers pueden quedarse en el build antiguo o encontrar una función bloqueada hasta que concedan el permiso. Un permiso nuevo de alto riesgo también puede necesitar una declaración de permisos en Play Console antes de que el build pueda publicarse siquiera. El consentimiento en tiempo de ejecución en el teléfono y la declaración en la Console son comprobaciones distintas.
Antes de lanzar a mitad de prueba: compara los permisos del manifest nuevo con el build en vivo. Si el set de permisos cambió, avisa a tus testers para que abran Play Store y actualicen a mano (y concedan el prompt nuevo), y reserva margen por si hay revisión de declaración.
Mitos comunes de la prueba cerrada, desmentidos
La mayor parte del pánico alrededor de actualizar se reduce a un puñado de mitos. Estos son los cinco que más quitan el sueño a los desarrolladores, con lo que es verdad de verdad:
Mito 1"Crear un release nuevo reinicia el reloj."
Mito 2"Desinstalar es lo mismo que dejar de participar."
Mito 3"Los 14 días son acumulativos."
Mito 4"Exactamente 12 testers bastan."
Mito 5"Los testers deben usar la app todos los días."
Qué reinicia el reloj y qué no
Aquí está toda la pregunta en una sola pantalla. Guárdala, haz captura o envíasela a quien en tu equipo sigue preguntando. Todo lo atado a tu build es seguro; solo lo atado a tu conteo de testers no lo es.
| Acción | ¿Reinicia el reloj de 14 días? |
|---|---|
| Subir un AAB nuevo al mismo segmento cerrado | No |
| Editar notas de release o metadatos de la ficha | No |
| Que un tester envíe feedback | No |
| Que tu app crashee en el dispositivo de un tester | No |
| Que un tester desinstale (sin dejar de participar) | No* |
| Que el conteo con participación aceptada baje de 12 | Sí |
| Que un tester deje de participar de forma formal por el enlace web | Sí** |
| Enviar un build roto que provoca abandonos bajo 12 | De forma indirecta |
| Pausar el segmento de prueba cerrada | Riesgo reportado |
| Sobrescribir la lista de testers y omitir testers activos | Riesgo reportado |
* No es dejar de participar, pero un tester sin la app instalada no la está probando. ** Solo si te deja con menos de 12 testers que cuentan. "Sí" aquí significa que tu primera fecha posible de solicitud se retrasa: los testers que se quedaron conservan sus días, pero un reemplazo empieza desde el día uno. Google documenta que subir un CSV sobrescribe la lista anterior y que pausar una prueba detiene sus actualizaciones; cómo se cuentan los días después no está documentado, así que trata las dos últimas filas como "no lo arriesgues".
Cómo cambió el requisito con el tiempo
Si estás leyendo tutoriales viejos, por eso los números no coinciden. La duración siempre fue 14 días de forma continua; solo se movió el conteo de testers.
Antes de noviembre de 2023 no había una prueba cerrada obligatoria para llegar a producción. Podías publicar sin reclutar testers.
Google anunció el requisito el 9 de noviembre de 2023. Las cuentas personales creadas después del 13 de noviembre de 2023 debían hacer una prueba cerrada con 20 testers con participación aceptada durante 14 días de forma continua. Las cuentas de organización estaban exentas.
El 11 de diciembre de 2024 el mínimo bajó de 20 a 12, con la duración de 14 días sin cambios. Las cuentas de organización siguen exentas.
Cualquier guía que todavía te diga que reclutes 20 testers está desactualizada. Cubrimos el cambio a fondo en qué cambió de 20 a 12 testers.
Cambios de política de 2026 que conviene conocer
La prueba cerrada no existe en el vacío. Unas pocas fechas de 2026 pueden cruzarse con tu timeline de lanzamiento: ninguna cambia cómo funciona el reloj de 14 días, pero pueden chocar con tu ventana si no miras el calendario:
Fechas 2026 que se cruzan con tu timeline
Fechas según la ayuda de Google Play Console (target API level) y el Android Developers Blog (verificación de desarrollador). El timing de la verificación es por fases y puede ampliarse en 2026-2027, así que confirma contra las páginas oficiales antes de planificar en torno a eso. Nuestra guía de requisitos de publicación 2026 sigue la lista completa.
Cómo PrimeTestLab mantiene tu reloj en marcha
Lo más difícil de la prueba cerrada no es entender las reglas: es mantener a 12 o más personas reales con participación aceptada y engagement durante 14 días seguidos mientras iteras. Eso es exactamente para lo que está construido PrimeTestLab. Aportamos testers en dispositivos reales, con participación aceptada, y te guiamos en el setup de Play Console para que el reloj arranque limpio y siga corriendo mientras envías correcciones. Ve nuestro servicio de prueba cerrada de Google Play para lo que incluye. Mantenemos una tasa de éxito de 99.9% en 12,100+ apps, con la prueba en línea en 4-6 horas.
Agregas a nuestros testers en Play Console, compartes la URL de la prueba y empiezan los 14 días. Desde ahí puedes publicar actualizaciones cuando lo necesites; los testers siguen con la participación aceptada mientras iteras.
Un plan por encima del mínimo de 12 testers te da testers extra que empiezan el mismo día, así que un abandono, incluido uno causado por un build defectuoso, no te deja por debajo de 12. Un colchón solo ayuda si esos testers aceptan participar pronto: un reemplazo tardío empieza sus propios 14 días. Los precios son por app, más un 5% de tarifa de servicio (mínimo $1.50) al pagar.
Preguntas frecuentes
¿Puedo actualizar mi app en la prueba cerrada sin reiniciar los 14 días?
Sí. Una actualización normal de la misma app en su canal de prueba cerrada en curso no reinicia por sí sola el tiempo de participación de los testers. Mantén a tus testers actuales aptos y con la participación aceptada. El build nuevo puede necesitar revisión y publicación antes de que los testers puedan instalarlo, así que comprueba la entrega por separado del requisito de pruebas.
¿Qué es lo único que reinicia el reloj de la prueba cerrada?
Google no publica una lista de reinicios que cubra todas las acciones de la Console. El requisito se refiere a la participación continua de cada tester. Un tester que sale y vuelve a unirse empieza de nuevo sus propios 14 días, y perder suficientes testers que cuentan puede retrasar tu solicitud. Un reemplazo nuevo empieza desde el día uno. Una actualización normal del build es otra cosa. En la documentación oficial de Google en español, a los testers también se les llama verificadores.
¿Cuál es la diferencia entre testers invitados y con participación aceptada?
Invitado significa que la cuenta está en tu lista de testers o en tu Google Group. Con participación aceptada significa que el tester abrió el enlace de la prueba con esa cuenta y se unió a la prueba. Agregar una dirección a la lista no completa la inscripción por sí solo. Pide a los testers que confirmen la cuenta y que luego instalen, usen la app y envíen comentarios útiles.
¿Los testers tienen que aceptar participar de nuevo después de una actualización?
Normalmente, no. Los testers aptos que ya están en la prueba reciben una actualización normal a través de Google Play sin volver a unirse a la misma prueba. Mantén intacta su inscripción y luego pídeles que revisen la ficha y el build instalado. La instalación automática depende de que la versión esté disponible y de la configuración del dispositivo, así que no prometas a cada tester la actualización en minutos.
¿Desinstalar es lo mismo que dejar de participar?
No. Desinstalar quita la app de un teléfono; dejar de participar cambia la participación en la prueba. Ni el número de instalaciones de hoy ni la lista de invitaciones de hoy demuestran una inscripción continua. Un tester que desinstaló tampoco puede probar esa instalación, así que confirma que sigue en la prueba y pídele que reinstale y siga probando.
¿Google quiere que envíe actualizaciones durante la prueba?
Google recomienda actuar según los comentarios de los testers y corregir los problemas, y la solicitud de acceso a producción pregunta qué cambiaste después de las pruebas. No publica un número obligatorio de versiones. Publica correcciones útiles cuando las necesites, registra qué cambió y vuelve a probarlas. No publiques versiones cosméticas solo para cumplir una supuesta regla de dos o tres actualizaciones.
¿Cuántos testers necesito de verdad para la prueba cerrada?
Para cuentas personales creadas después del 13 de noviembre de 2023, el mínimo es de 12 testers que hayan seguido cada uno con la participación aceptada durante los últimos 14 días consecutivos cuando hagas la solicitud. Reclutar testers extra pronto te da un colchón. Los reemplazos que se suman tarde no heredan los días de los testers que se fueron, y ningún número de testers garantiza el acceso a producción.
¿Tengo que publicar dos o tres actualizaciones para superar la prueba?
La guía publicada de Google no fija esa cuota. Pregunta por las pruebas, los comentarios, los cambios y si la app está lista. Si las pruebas encuentran un problema real, corrígelo y registra la nueva prueba. Si no lo encuentran, describe las pruebas con honestidad. Un número de versiones por sí solo ni demuestra que las pruebas fueron útiles ni garantiza que se conceda el acceso a producción.
Mi versión está disponible, ¿por qué mi tester sigue con la versión antigua?
Revisa la cuenta de Google del tester, su inscripción en el canal, el porcentaje de lanzamiento y el versionCode. Luego pídele que abra la ficha de Play Store y busque Actualizar. La actualización automática puede estar desactivada o retrasarse por las condiciones del dispositivo. Confirma que el build se instaló de verdad; la fecha de actualización de la ficha no basta.
¿"En revisión" pausa mi prueba de 14 días?
Una actualización en revisión está esperando a que Google procese ese build. Google no documenta que la revisión de una actualización normal pause el tiempo de participación que ya llevan tus testers. Comprueba que la prueba en curso sigue disponible y que la inscripción está intacta. Otro envío puede retrasar la revisión de la versión, que es algo distinto del requisito de pruebas continuas.
¿Deben los testers salir y volver a unirse para recibir la actualización?
No. Salir de la prueba cerrada y volver a unirse no arregla una actualización, y rompe los días consecutivos de participación de ese tester. Primero revisa la publicación, la cuenta del tester, el lanzamiento y el versionCode; luego prueba la vía normal de actualización de Play Store. Repara aparte una inscripción que de verdad esté mal, sabiendo lo que eso supone para los 14 días de ese tester.
Conclusión
Resumen
Actualizar tu app durante la prueba cerrada de 14 días es seguro, normal y se fomenta. Google mide la participación sin interrupción de cada tester, así que una actualización normal en el mismo canal cerrado no reinicia los 14 días de tus testers. Los riesgos reales son perder testers que cuentan, que los testers dejen de participar de forma formal o publicar un build tan roto que los testers abandonen. Publica correcciones reales, actúa según los comentarios y protege tu número de testers con un colchón reclutado pronto. Si quieres ayuda para mantener 12 o más testers con participación aceptada, PrimeTestLab aporta de 12 a 25 testers reales desde $19.99, más un 5% de tarifa de servicio (mínimo $1.50), con la prueba en marcha en 4-6 horas. Si no se concede el acceso a producción tras la prueba completa, eliges: repetición gratis o reembolso completo. Ver planes de precios →