Beta testing de tu app en 2026: TestFlight, canales de Google Play y el mito de los 12 testers
Antes de publicar en producción tienes que probar la app con usuarios reales. En iOS eso se hace con TestFlight; en Android, con los canales de prueba de Google Play (interno, cerrado y abierto). La regla de "12 testers durante 14 días" que ves circular en foros solo afecta a cuentas personales de Google Play creadas a partir del 13 de noviembre de 2023: si publicas desde una cuenta de empresa, estás exento. Aquí tienes cómo montar el beta en ambas tiendas y qué pruebas merece la pena hacer de verdad.
El mito de los 12 testers
Google exige que las cuentas de desarrollador personales creadas a partir del 13 de noviembre de 2023 pasen por una prueba cerrada antes de poder publicar en producción: al menos 12 testers inscritos de forma continua durante 14 días. En diciembre de 2024 Google bajó el mínimo de 20 a 12, pero mantuvo la ventana de 14 días.
El detalle que se pierde en el pánico de los foros: la regla no aplica a cuentas de organización. Si tu empresa publica con una cuenta de Play Console de tipo organización (la que se abre con un D-U-N-S), no tienes que reunir 12 testers ni esperar 14 días para pasar a producción. Tampoco aplica a las cuentas personales anteriores a esa fecha.
Para el perfil que suele leernos (un CTO o un responsable de producto que publica en nombre de una empresa), esto significa que el problema real no es "cómo consigo 12 testers", sino "qué beta testing tiene sentido antes de lanzar". Si vas a abrir cuenta, ábrela como organización desde el principio y te ahorras la fricción. Aquí explicamos cómo se monta la cuenta de empresa con el D-U-N-S.
TestFlight: el beta de iOS
En iOS todo pasa por TestFlight, integrado en App Store Connect. Tienes dos tipos de tester:
- Testers internos: hasta 100 personas con un rol en App Store Connect. Reciben las builds a los pocos minutos de subirlas, sin revisión de Apple. Es lo que usas para tu equipo y para QA interno.
- Testers externos: hasta 10.000 personas, por invitación de correo o mediante un enlace público. La primera build de cada versión que mandas a externos pasa por la Beta App Review de Apple, que suele tardar alrededor de 24 horas (a veces menos, a veces hasta 48).
Dos límites que conviene tener presentes. Las builds de TestFlight caducan a los 90 días desde su subida; pasado ese plazo, el tester ve "build caducada" y no puede abrir la app hasta que subas una nueva. Y puedes organizar a los testers en grupos, lo que te permite dar distintas builds a distintos públicos: una para diseño, otra para el cliente.
Los tres canales de Google Play
Play Console separa las pruebas en tres canales antes de producción:
| Canal | Para qué | Revisión | Cuenta para producción |
|---|---|---|---|
| Interno | Equipo y QA, hasta 100 testers | No | No |
| Cerrado | Beta con usuarios reales | Sí (aplicación) | Sí (el único que cuenta) |
| Abierto | Beta pública y descubrible | Sí | No |
El canal interno es el equivalente a los testers internos de TestFlight: sin revisión, disponible en minutos, hasta 100 testers y sin mínimos. Para iterar rápido con tu equipo, es donde vives.
El canal cerrado es el que Google exige a las cuentas personales nuevas para pasar a producción, y el único que cuenta para el requisito de los 12 testers durante 14 días. El reloj de esos 14 días empieza cuando la release está aprobada y tienes 12 o más testers dentro.
El canal abierto hace tu versión de prueba visible y descargable por cualquiera desde la ficha de Play. Sirve para recoger feedback a gran escala, pero no vale como sustituto del cerrado a efectos del requisito de producción.
Qué beta testing hacer de verdad
El requisito de Google es una puerta de cumplimiento, no un plan de pruebas. Cumplirlo no te dice si tu app está lista. Esto es lo que hacemos en Dribba después de +300 proyectos publicados en ambas tiendas:
- El equipo y QA van al canal interno de Play y a los testers internos de TestFlight. Builds en minutos, iteración rápida, cero espera de revisión.
- La beta con usuarios reales va al canal cerrado de Play y a un grupo de externos en TestFlight. Aquí cazas los fallos que no salen en el laboratorio: dispositivos raros, conexiones malas, permisos denegados, el flujo de pago con una tarjeta de verdad.
- El canal abierto, solo si buscas volumen de feedback antes de un lanzamiento grande, y sabiendo que expones una versión sin terminar en tu ficha pública.
Para quién sí y para quién no. Si publicas con cuenta de empresa, olvídate de la carrera de los 12 testers y monta una beta cerrada con las personas adecuadas: usuarios que se parezcan a los de producción. Si tu app es interna y no va a las tiendas públicas, ni TestFlight ni los canales de Play son tu camino; mira la distribución con Apple Business Manager y Managed Google Play, que cubrimos en esta guía.
Los errores que más vemos
- Contratar "servicios de 12 testers". Van contra las políticas de Play y te dan una señal inútil: 12 desconocidos que abren la app una vez y desaparecen no prueban nada, y encima arriesgas la cuenta.
- Usar el canal abierto para saltarte el cerrado. No cuenta para producción y expone tu beta a cualquiera.
- Olvidar que las builds de TestFlight caducan a los 90 días. Si tu ciclo de revisión con cliente es largo, sube una build fresca antes de la demo.
- Empezar el reloj de los 14 días tarde. Si sabes que vas con cuenta personal nueva, arranca el cerrado el primer día, no la semana antes de lanzar.
En resumen
TestFlight para iOS, canales interno, cerrado y abierto para Android, y una regla de los 12 testers que casi con seguridad no te aplica si publicas como empresa. El beta testing que sirve pone tu app en manos de usuarios reales antes que nadie. Cumplir el requisito de Google es otra cosa: un trámite.
Si estás preparando el lanzamiento de una app y quieres montar el pipeline de pruebas y publicación bien desde el principio, en Dribba lo hacemos cada semana. También tienes nuestra guía de cómo publicar en ambas tiendas y otra de cómo evitar rechazos con el texto exacto de la tienda.
