Pruebas abiertas Google Play 2026: tope 1.000+ vs 12 testers

Ese requisito es justo el hueco que PrimeTestLab se construyó para cerrar.

Cuatro preguntas traen aquí a casi todo el mundo: si hay desconocidos que pueden encontrar mi app, si de verdad necesito 1.000 testers, si los comentarios de la beta van a destrozar mi calificación y si puedo usar esto en lugar de rogarle a doce personas que instalen algo. Tres de ellas tienen respuestas limpias en la propia documentación de Google y la cuarta es la que duele. La configuración en la consola va primero aquí abajo, porque para eso está esta página, y la cuarta pregunta se lleva la sección justo después. Todo lo que hay aquí está vigente a fecha de 12 de agosto de 2026, contrastado con la página de requisitos de prueba de Google (respuesta de Ayuda 14151465), su página de configuración de pruebas (respuesta de Ayuda 9845334) y la página de la función de pruebas abiertas de Play Console. Cuando una afirmación se apoya en un hilo de la comunidad y no en Google, la página lo etiqueta así en lugar de ascenderla a hecho.

Qué son en realidad las pruebas abiertas

La mitad de la confusión la causa el nombre. Quien ve "Open testing" en Play Console lo lee como un estado de publicación que quizá activó sin querer, y quien lee "testing" da por hecho que la app tiene que estar oculta. Ninguna de las dos cosas es cierta. Las pruebas abiertas son un canal de distribución que convive con las pruebas internas, las pruebas cerradas y producción, y su rasgo definitorio es que hay desconocidos que pueden llegar hasta él.

En qué se diferencia de una versión de producción

Una versión de producción es la app. Una prueba abierta es una compilación paralela en la que los usuarios que cumplen los requisitos aceptan participar, y las dos pueden convivir: los usuarios de producción se quedan con la versión de producción, y quienes se unen a la prueba abierta reciben en su lugar la versión de prueba. Google lo resuelve por version code, y sirve a cada usuario el version code compatible más alto entre los canales para los que cumple los requisitos; por eso un tester abierto que además es usuario de producción puede acabar en cualquiera de las dos compilaciones según lo que hayas publicado en cada sitio.

La diferencia práctica que más importa es la reversibilidad. Terminar una prueba abierta es poner el canal en pausa: los testers dejan de recibir actualizaciones de prueba y la app se queda instalada en sus dispositivos. No existe una salida discreta equivalente para un lanzamiento a producción que salió demasiado pronto. Para ver los cuatro canales uno al lado del otro, la comparativa de pruebas internas, cerradas y abiertas cubre la matriz completa; este artículo se queda en las pruebas abiertas.

Las pruebas abiertas de un vistazo

Hay una fila que merece un aviso temprano, porque es la que trae aquí a casi todo el mundo: "ningún mínimo de testers reales" y "un tope de al menos 1.000" son dos afirmaciones distintas sobre dos cosas distintas. El dial del tope lo desmonta como es debido.

Cómo configurar las pruebas abiertas en Play Console

Antes de empezar

Tienen que cumplirse tres cosas para que el canal coopere. Primero, las pruebas abiertas tienen que estar disponibles para tu cuenta, lo que en una cuenta personal creada después del 13 de noviembre de 2023 significa que ya te hayan concedido el acceso a producción. Segundo, tiene que haber un Android App Bundle subido, porque los controles de testers se rellenan a partir de un bundle existente. Tercero, la ficha de la tienda tiene que estar lista para verse: Google recomienda que la app y la ficha estén listas para ser visibles en Google Play antes de que elijas las pruebas abiertas, y esa recomendación está trabajando de verdad, no cubriéndose las espaldas.

El artículo específico de Google sobre configuración de pruebas abrevia ese mismo destino como Testing y luego Open testing, mientras que su página de requisitos de prueba escribe la ruta larga. Si tu consola agrupa el menú de forma distinta a una captura que hayas encontrado por ahí, la razón es esa, y el destino es el mismo en cualquier caso.

Configura los testers y los comentarios

En la página de Open testing, entra en la pestaña Testers y despliega Manage testers. Si esa sección está vacía, la instrucción de Google es concreta: asegúrate de haber subido un app bundle. No hay nada que configurar hasta que exista una compilación.

El control de participación tiene dos ajustes. Unlimited viene seleccionado por defecto. Limited number te deja fijar un máximo, y Google no acepta un máximo por debajo de 1.000. Esa única frase provoca casi toda la confusión que hay con este canal, así que tiene su propia sección y su instrumento más abajo.

Después añade una URL o una dirección de correo para comentarios, de modo que los testers tengan dónde enviar sus comentarios privados, copia el enlace de prueba para compartir con el que vas a reclutar y pulsa Save changes. El enlace para aceptar participar solo aparece cuando el estado de la app es Published; no se muestra en una app en Draft ni en Pending publication, y conviene saberlo antes de pasarte una tarde buscando un enlace que todavía no puede existir.

Hay un control que queda fuera de ese panel y que se salta todo el mundo: la disponibilidad por país y región. Google documenta cómo gestionar la disponibilidad por país en los canales de prueba cerrada y abierta de una app, y "abierta" significa pública dentro de los mercados que hayas seleccionado, no en todas partes. Es la razón silenciosa de que un enlace correcto te funcione a ti y le falle al tester al que se lo enviaste.

La configuración, en orden

1. 01
   Confirma que las pruebas abiertas están disponibles para tu cuenta

   En una cuenta personal creada después del 13 de noviembre de 2023, el acceso a producción ya tiene que estar concedido. Un canal en gris suele ser cuestión de requisitos, no un fallo.

2. 02
   Abre el canal

   Test and release, luego Testing y luego Open testing.

3. 03
   Asegúrate de haber subido un app bundle

   Google señala esto explícitamente como la solución cuando la sección Manage testers está vacía.

4. 04
   Abre la pestaña Testers y despliega Manage testers

   Ahí es donde están el ajuste de participación y el enlace para compartir.

5. 05
   Fija la capacidad de participantes

   Unlimited, que es el valor por defecto, o Limited number con un tope de al menos 1.000. El tope es un techo, no un objetivo de reclutamiento.

6. 06
   Añade una URL o dirección de correo para comentarios

   Los comentarios de la prueba se leen en Play Console, en Ratings and reviews y luego Testing feedback.

7. 07
   Copia el enlace de prueba para compartir

   Google te da una URL que puedes distribuir por web o por correo; cualquiera que cumpla los requisitos y la tenga puede acceder a la prueba abierta.

8. 08
   Pulsa Save changes

   La configuración es algo aparte de la versión. Guardar aquí no publica nada.

9. 09
   Revisa la disponibilidad por país y región

   Google documenta la disponibilidad por país en los canales de prueba cerrada y abierta. Selecciona los mercados en los que debe correr la prueba en lugar de dar por hecho que todos los países de Play están activos, porque un usuario que quede fuera de esa disponibilidad no puede unirse con un enlace que por lo demás es correcto.

10. 10
    Crea y lanza la versión de la prueba abierta

    Prepara la versión en el canal de prueba abierta y lánzala. Este es el paso que pone el canal en marcha.

11. 11
    Verifica el acceso de los testers y dale tiempo a la propagación

    Google dice que, después de publicar una prueba por primera vez, el enlace puede tardar unas horas en estar disponible, y que los cambios publicados después pueden tardar varias horas.

¿Las pruebas abiertas pueden sustituir a la prueba cerrada de 12 testers?

Este es el malentendido más caro de todos los resultados de búsqueda sobre pruebas abiertas. El razonamiento que hay detrás es del todo lógico: abierta significa que cualquiera puede unirse, doce testers son difíciles de encontrar, luego las pruebas abiertas tienen que ser la manera de saltarse el problema del reclutamiento. La propia documentación de Google cierra esa puerta en una sola frase.

Leído en secuencia con el resto de esa página, significa que el orden es fijo para las cuentas afectadas: primero la prueba cerrada, segundo el acceso a producción, y tercera y opcional la prueba abierta. El proceso publicado por Google no ofrece ninguna configuración ni ningún canal de pruebas alternativo que invierta esos dos primeros pasos en una cuenta afectada.

El acceso a producción no es una versión de producción

Estas dos expresiones se usan como si fueran lo mismo y no lo son. El acceso a producción es un permiso que Google concede a tu cuenta para una app después de revisar tu prueba cerrada y tus respuestas sobre si estás listo. Una versión de producción es que tú publiques de verdad una compilación en el canal Production para el público general.

Una vez concedido el acceso, Google dice que quedan disponibles tanto el canal Production como Open testing. A partir de ahí puedes hacer una prueba abierta visible públicamente aunque la app no haya tenido nunca una versión de producción. Esa es la secuencia que debería querer la mayoría de los primeros lanzamientos: la prueba cerrada cumple el requisito, la prueba abierta recoge señal del mundo real y la versión de producción llega cuando tú decidas.

A qué cuentas se aplica esto de verdad

Google fija el requisito para cuentas personales de desarrollador creadas después del 13 de noviembre de 2023, algo que fue hace ya 2 años y 9 meses. Hay dos aclaraciones que importan, y en las dos es donde otras páginas se pasan de frenada:

• La fecha es un corte, no un anuncio. La publicación oficial del anuncio de Google lleva fecha del 9 de noviembre de 2023. La página del requisito usa el 13 de noviembre de 2023 como fecha de corte de creación de la cuenta. Escribir "anunciado el 13 de noviembre" es incorrecto aunque el número esté bien.
• El número era 20 antes de ser 12. Google bajó el umbral de 20 testers a 12 el 11 de diciembre de 2024, hace ya 1 año y 8 meses, y la duración de 14 días no cambió. Las páginas que siguen imprimiendo 20 como requisito actual están desactualizadas, no son más estrictas. La historia completa está en el artículo Cambio de 20 a 12 testers.

Las cuentas de organización quedan fuera de la redacción de esa página: Google acota el requisito a las cuentas personales que entran en él y no lo formula como una regla universal con una exención explícita para organizaciones. Respuestas oficiales en la comunidad dicen que las cuentas de organización no tienen el requisito de pruebas y, por otro lado, algunos desarrolladores han contado que sus cuentas de organización migradas seguían mostrando un requisito de pruebas heredado. La lectura segura es de alcance, no de inmunidad: Parcial Reportado por la comunidad Si tu consola sigue mostrando el requisito, tu consola manda para tu cuenta. La decisión sobre el tipo de cuenta es tema del artículo sobre cuenta personal vs cuenta de organización.

¿Una app en pruebas abiertas es pública o se puede buscar?

Lo de que "las pruebas abiertas son solo por invitación" es una de las respuestas erróneas más resistentes de este tema, y se la puede ver corregida en los mismos hilos de foro donde aparece. Vale la pena decirlo claro: una prueba abierta no es una beta privada con un nombre que suena público. Hay desconocidos que pueden encontrarla, unirse y usar tu app sin hablar nunca contigo.

Eso tiene una consecuencia que se subestima hasta que está en marcha: la visibilidad pública expone al mercado general el nombre, el icono, la descripción, las capturas y la propia existencia de tu app, y por eso Google recomienda que la app y la ficha de la tienda estén listas para verse en Google Play antes de que elijas este canal. Que la competencia se ponga a mirar es una deducción práctica a partir de esa visibilidad pública, no algo de lo que hable Google; el hecho documentado es simplemente que la ficha se puede encontrar.

Que se pueda descubrir no significa que sea inmediato

Google documenta que la prueba se puede descubrir. No publica un tiempo garantizado para que una app aparezca en la búsqueda, y lo que dice sobre propagación es modesto: después de publicar una prueba por primera vez, el enlace puede tardar unas horas en estar disponible, y los cambios publicados después pueden tardar varias horas. Más allá de eso, hay fichas reales que a veces se comportan mal. Un hilo de abril de 2026 en la Google Play Developer Community informa de una ficha de prueba abierta que devolvía un 404 mientras el canal parecía activo. Reportado por la comunidad Eso es un caso de soporte, no un periodo de espera documentado, y la sección de solución de problemas separa las dos cosas.

¿Los testers abiertos dejan calificaciones o reseñas públicas?

El miedo que trae a la gente a esta pregunta es concreto y conviene nombrarlo: sale la primera versión, usuarios reales encuentran los errores tempranos y una oleada de reseñas de una estrella deja la calificación de la app tocada para siempre antes de que tenga público. Ese es un riesgo real de publicar en producción demasiado pronto. No es un riesgo de las pruebas abiertas.

Qué hacen en realidad los comentarios

La afirmación que sí puedes hacer y la que conviene evitar

La distinción importa si estás armando tu propio plan de lanzamiento alrededor de ella. "Los comentarios de prueba son privados" es defendible y comprobable. "Los beta testers nunca pueden dañar mi calificación" es una afirmación más grande de lo que dice la documentación, y esa versión ampliada es la que acabará sorprendiendo a alguien.

¿Necesitas 1.000 testers para las pruebas abiertas?

Cada vez que lees que "las pruebas abiertas exigen 1.000 testers" se están confundiendo dos cosas distintas. Una es un límite de configuración de un campo de Play Console. La otra es un requisito de participación que, en las pruebas abiertas, no existe. Si fijas el tope en 1.000 y aceptan participar 37 personas, tienes 37 testers abiertos y una prueba abierta perfectamente normal. El 37 es aritmética de ejemplo, no un umbral que Google publique.

También conviene separar esto del número que sí te obliga. El 12 de "12 testers durante 14 días continuos" es un mínimo real, y pertenece a la prueba cerrada, camino del acceso a producción. El 1.000 de aquí es un piso sobre un techo, en un canal completamente distinto. Dos números, dos canales, una colisión muy habitual.

Si lo que quieres de verdad es un grupo pequeño y escogido a mano, el tope no es tu problema y las pruebas abiertas no son tu canal. Una lista de invitación controlada es justo para lo que sirven las pruebas cerradas, y la comparativa de canales explica cuál encaja con cada trabajo.

Cuándo deberías usar de verdad las pruebas abiertas

Cuatro casos en los que el canal se gana esa exposición

• Lanzar país por país

  Google plantea las pruebas abiertas para probar un mercado nuevo y adaptar la app a él antes de un lanzamiento más amplio. Una beta pública en un solo país te da diversidad real de dispositivos, condiciones de red reales y comentarios reales sobre el idioma que ninguna lista de amigos invitados puede reproducir.

• Mirar las métricas antes de comprometerte

  Google describe las pruebas abiertas como una forma de recoger comentarios cuantitativos y cualitativos a gran escala, probar funciones previas al lanzamiento y vigilar métricas antes de publicar. Si lo que necesitas son números y no opiniones, un grupo público más grande suele ser la vía más rápida para conseguirlos con valor estadístico: la retención, la conversión, la carga del backend y la diversidad de dispositivos se leen de forma muy distinta a escala que en doce instalaciones invitadas.

• Comprobaciones de estabilidad, retención y monetización

  Google Ads describe el uso de una prueba abierta para evaluar la estabilidad, la retención, la monetización y la eficacia de los creativos publicitarios antes de un lanzamiento amplio. Si piensas hacer una campaña de app sobre la prueba abierta, Google Ads recomienda además no limitar las descargas de la prueba abierta en Play Store, que es un segundo motivo para dejar el ajuste de participación en Unlimited.

• Un último vistazo a una función casi terminada

  El canal está pensado para la etapa en la que la compilación está casi lista y las incógnitas que quedan tienen que ver con el comportamiento a escala, no con errores evidentes. Los comentarios llegan en privado, así que nada de lo que aprendas en esta fase aterriza en tu calificación pública.

Tres motivos que no son motivos

• Para evitar reclutar a 12 testers cerrados. En una cuenta personal creada después del 13 de noviembre de 2023, esto no funciona en absoluto: el canal está detrás del mismo requisito. Es la razón por la que casi todo el mundo lee esta página, y es la única respuesta que no se puede suavizar.
• Para mantener privada la app o la ficha. Esto es justo lo contrario de lo que hace el canal. Si tu motivo para probar en silencio es que la idea todavía no es pública, las pruebas abiertas juegan activamente en tu contra.
• Para probar con un grupo pequeño y escogido a mano. Eso son las pruebas cerradas. Poner a una prueba abierta el tope mínimo permitido de 1.000 no la convierte en una prueba privada; solo fija un techo al que nunca vas a llegar.

De la prueba cerrada a la abierta y a producción

Qué se traslada de verdad

"Promocionar" una compilación suena a un único botón que sube tu app un peldaño. El comportamiento que documenta Google es más mecánico y más útil de entender: la distribución se decide usuario por usuario según el version code. Cada usuario recibe el version code compatible más alto publicado en cualquier canal para el que cumpla los requisitos, y por eso un tester abierto que además es usuario de producción no se queda en la compilación de prueba por fidelidad. Se queda porque esa compilación tiene el version code más alto.

El mismo modelo explica la etiqueta Promoted. Un canal de prueba aparece como Promoted cuando sus bundles activos están activos también en el canal de reserva más estable, es decir, cuando no hay nada en el canal de prueba que producción no tenga ya. Es una descripción de un estado, no una acción que tú ejecutes.

¿Las pruebas abiertas no aparecen en Google Play? Comprueba esto primero

Comprueba cuatro estados antes de tratar esto como un problema de indexación de Play o como un caso de soporte. La app todavía no cumple los requisitos del canal, la versión se configuró pero nunca se lanzó, la app no está en estado Published, o no ha pasado suficiente tiempo desde la primera publicación. Ahí viven las explicaciones normales; todo lo que venga después es de verdad raro.

Qué no hay que concluir

No existe ninguna cifra publicada de descargas que una app necesite antes de aparecer en la búsqueda de Play. Esa afirmación circula como experiencia personal en hilos de foros y ninguna fuente primaria la respalda. Tampoco hay un tiempo de indexación garantizado en la búsqueda: Google documenta que la prueba se puede descubrir y da orientación sobre la propagación de enlaces y cambios, y ahí se detiene. Si una ficha sigue rota mucho después de la ventana de propagación documentada, la respuesta honesta es que tienes un caso de soporte, no un ajuste que se te pasó.

Si el problema está más bien del lado cerrado, y tus testers dicen que no ven la app en absoluto, eso tiene su propio conjunto de causas: el artículo sobre la app no disponible para los testers cubre los fallos de enlace y de requisitos, y añadí 12 testers pero 0 aceptaron participar cubre el problema de conteo que frena el reloj del acceso a producción.

Cómo ayuda PrimeTestLab

El problema del reclutamiento es todo el cuello de botella. La mayoría de quienes leen esto sabe construir la app, subir el bundle, escribir la ficha y responder el cuestionario. Lo que los frena durante semanas es encontrar a una docena de personas con cuenta de Google dispuestas a instalar algo, seguir participando y no desinstalarlo en silencio el día nueve. Eso no es un problema de ingeniería, y justo por eso resulta tan frustrante quedarse bloqueado ahí.

En 7,400+ apps, la tasa de éxito del lado de los testers se ha mantenido en 99.9%, y ese número habla de que la prueba corra limpia, no de la decisión de Google sobre tu app. La aprobación depende de que tu app cumpla las políticas de Google, y ningún servicio puede prometerla. Lo que hace una prueba gestionada es quitarte de encima el único requisito que es pura logística, para que los catorce días transcurran de verdad. Si una prueba terminada acaba igualmente en una negativa, la política de reembolsos detalla la repetición gratis y el reembolso completo, y también los casos que no cubre.

Preguntas frecuentes

En resumen

Si lo que te está frenando de verdad es ese requisito, es justo la parte que puedes delegar. Ver planes y precios →