Teste aberto Google Play 2026: limite 1.000+ vs 12 testadores

Esse portão é justamente a lacuna que a PrimeTestLab foi criada para fechar.

Quatro perguntas trazem quase todo mundo até esta página: desconhecidos conseguem encontrar o meu app, eu preciso mesmo de 1.000 testadores, o feedback do beta vai destruir a minha nota, e dá para usar isso em vez de implorar para doze pessoas instalarem alguma coisa. Três delas têm respostas limpas na própria documentação do Google, e a quarta é a que dói. A configuração na Console vem primeiro aqui embaixo, porque é para isso que esta página existe, e a quarta pergunta ganha a seção logo em seguida. Tudo aqui está atualizado em 12 de agosto de 2026, conferido na página de requisitos de teste do Google (resposta 14151465 da Ajuda), na página de configuração de testes (resposta 9845334) e na página do recurso de teste aberto da Play Console. Quando uma afirmação se apoia em uma discussão da comunidade e não no Google, a página marca isso em vez de promover a afirmação a fato.

O que o teste aberto é de fato

O nome causa metade da confusão. Desenvolvedores que veem "Open testing" na Play Console leem aquilo como um status de publicação que talvez tenham ligado sem querer, e desenvolvedores que leem "teste" supõem que o app precisa estar escondido. Nenhum dos dois está certo. O teste aberto é uma faixa de distribuição que fica ao lado do teste interno, do teste fechado e da produção, e a característica que o define é que desconhecidos conseguem chegar até ele.

Como isso difere de uma versão em produção

Uma versão em produção é o app. Um teste aberto é um build paralelo do qual usuários elegíveis aceitam participar, e os dois podem rodar ao mesmo tempo: quem está na produção continua na versão de produção, e quem entra no teste aberto recebe a versão de teste. O Google resolve isso pelo código de versão, entregando a cada usuário o maior código de versão compatível entre as faixas para as quais ele é elegível, e é por isso que um testador aberto que também é usuário de produção pode acabar em qualquer um dos dois builds, dependendo do que você publicou onde.

A diferença prática que mais importa é a reversibilidade. Encerrar um teste aberto é pausar a faixa: os testadores param de receber atualizações de teste e o app continua instalado nos aparelhos deles. Não existe uma saída discreta equivalente para um lançamento em produção que saiu cedo demais. Para a visão lado a lado das quatro faixas, a comparação entre teste interno, fechado e aberto cobre a matriz completa; este artigo fica no teste aberto em si.

O teste aberto em resumo

Uma linha merece um aviso logo de cara, porque é a linha que traz a maioria das pessoas até esta página: "nenhum número mínimo de testadores reais" e "um limite de no mínimo 1.000" são duas afirmações diferentes sobre duas coisas diferentes. O seletor de limite desmonta isso direito.

Como configurar o teste aberto na Play Console

Antes de começar

Três coisas precisam ser verdade antes de a faixa colaborar. Primeira: o teste aberto tem que estar disponível para a sua conta, o que, para uma conta pessoal criada depois de 13 de novembro de 2023, significa que o acesso de produção já foi concedido. Segunda: um Android App Bundle precisa ter sido enviado, porque os controles de testadores são preenchidos a partir de um bundle existente. Terceira: a ficha da loja precisa estar pronta para ser vista, já que o Google recomenda que o app e a ficha da loja estejam prontos para ficar visíveis no Google Play antes de você escolher o teste aberto, e essa recomendação está fazendo trabalho de verdade, não se protegendo.

O artigo do Google dedicado à configuração de testes abrevia o mesmo destino como Testing e depois Open testing, enquanto a página de requisitos de teste escreve o caminho mais longo. Se a sua Console agrupa o menu de um jeito diferente de uma captura de tela que você achou por aí, o motivo é esse, e o destino é o mesmo dos dois jeitos.

Configure os testadores e o feedback

Na página Open testing, abra a aba Testers e expanda Manage testers. Se essa seção estiver vazia, a instrução do Google é específica: confirme que um app bundle foi enviado. Não há nada para configurar enquanto não existir um build.

O controle de participantes tem duas opções. Unlimited vem selecionada por padrão. Limited number deixa você definir um máximo, e o Google não aceita um máximo abaixo de 1.000. Essa única frase causa quase toda a confusão em torno dessa faixa, então ela ganha uma seção própria e um instrumento mais abaixo.

Depois adicione uma URL de feedback ou um endereço de e-mail para os testadores terem onde mandar feedback privado, copie o link de teste compartilhável para o recrutamento e selecione Save changes. O link de participação só aparece quando o status do app é Published; ele não aparece para um app em Draft ou Pending publication, o que vale saber antes de você passar uma tarde procurando um link que ainda não pode existir.

Um controle fica fora desse painel e é pulado o tempo todo: a disponibilidade por país e região. O Google documenta o gerenciamento da disponibilidade por país nas faixas de teste fechado e aberto de um app, e "aberto" quer dizer público dentro dos mercados que você selecionou, não em toda parte. É a razão silenciosa de um link correto funcionar para você e falhar para o testador a quem você mandou.

A configuração em ordem

1. 01
   Confirme que o teste aberto está disponível para a sua conta

   Para uma conta pessoal criada depois de 13 de novembro de 2023, o acesso de produção já precisa ter sido concedido. Uma faixa esmaecida costuma ser elegibilidade, não defeito.

2. 02
   Abra a faixa

   Test and release, depois Testing, depois Open testing.

3. 03
   Confirme que um app bundle foi enviado

   O Google aponta isso explicitamente como a solução quando a seção Manage testers está vazia.

4. 04
   Abra a aba Testers e expanda Manage testers

   É aqui que ficam a configuração de participantes e o link compartilhável.

5. 05
   Defina a capacidade de participantes

   Unlimited, que é o padrão, ou Limited number com um limite de no mínimo 1.000. O limite é um teto, não uma meta de recrutamento.

6. 06
   Adicione uma URL de feedback ou um endereço de e-mail

   O feedback do teste é lido na Play Console em Ratings and reviews, depois Testing feedback.

7. 07
   Copie o link de teste compartilhável

   O Google fornece uma URL que você pode distribuir por site ou e-mail; qualquer pessoa elegível que a tenha consegue acessar o teste aberto.

8. 08
   Selecione Save changes

   A configuração é separada da versão. Salvar aqui não publica nada.

9. 09
   Revise a disponibilidade por país e região

   O Google documenta a disponibilidade por país nas faixas de teste fechado e aberto. Selecione os mercados em que o teste deve rodar em vez de supor que todos os países da Play Store estão ativos, porque um usuário fora dessa disponibilidade não consegue entrar mesmo com um link que está correto.

10. 10
    Crie e lance a versão do teste aberto

    Prepare a versão na faixa de teste aberto e lance. É esse passo que coloca a faixa no ar.

11. 11
    Confirme o acesso dos testadores e dê tempo para a propagação

    O Google diz que, depois de você publicar um teste pela primeira vez, o link pode levar algumas horas para ficar disponível, e mudanças publicadas depois podem levar várias horas.

O teste aberto pode substituir o teste fechado de 12 testadores?

Esse é o mal-entendido mais caro de todos os resultados de busca sobre teste aberto. O raciocínio por trás dele é totalmente lógico: aberto quer dizer que qualquer um pode entrar, doze testadores são difíceis de achar, logo o teste aberto deve ser o jeito de pular o problema do recrutamento. A própria documentação do Google fecha essa porta em uma frase.

Lida na sequência com o resto daquela página, a frase significa que a ordem é fixa para as contas afetadas: teste fechado primeiro, acesso de produção depois, teste aberto em terceiro e opcional. O processo publicado pelo Google não oferece nenhuma configuração nem faixa de teste alternativa que inverta essas duas primeiras etapas para uma conta abrangida.

Acesso de produção não é versão em produção

Essas duas expressões são usadas como sinônimos e não são a mesma coisa. O acesso de produção é uma permissão que o Google concede à sua conta para um app depois de analisar o seu teste fechado e as suas respostas sobre prontidão. Uma versão em produção é você de fato publicar um build na faixa Produção para o público em geral.

Depois que o acesso é concedido, o Google diz que tanto a faixa Produção quanto o Open testing ficam disponíveis. A partir daí, dá para rodar um teste aberto que qualquer um encontra mesmo que o app nunca tenha tido uma versão em produção. Essa é a sequência que a maioria dos primeiros lançamentos deveria querer: o teste fechado cumpre o requisito, o teste aberto colhe sinal do mundo real, e a versão em produção acontece quando você decidir.

A quais contas isso realmente se aplica

O Google declara o requisito para contas pessoais de desenvolvedor criadas depois de 13 de novembro de 2023, o que foi há 2 anos e 9 meses. Duas ressalvas importam, e as duas são pontos em que outras páginas exageram:

• A data é um corte, não um anúncio. O post oficial de anúncio do Google é de 9 de novembro de 2023. A página do requisito usa 13 de novembro de 2023 como data de corte da criação da conta. Escrever "anunciado em 13 de novembro" é errado, mesmo que o número esteja certo.
• O número era 20 antes de ser 12. O Google reduziu o limite de 20 testadores para 12 em 11 de dezembro de 2024, o que foi há 1 ano e 8 meses, e a duração de 14 dias não mudou. Páginas que ainda imprimem 20 como requisito atual estão desatualizadas, não mais rígidas. A história completa está no artigo mudança de 20 para 12 testadores.

As contas organizacionais ficam fora do texto dessa página: o Google limita o requisito às contas pessoais que se enquadram e não o formula como uma regra universal com uma isenção nomeada para organizações. Respostas oficiais na comunidade dizem que as contas organizacionais não têm o requisito de teste e, à parte disso, alguns desenvolvedores relataram contas organizacionais migradas que ainda exibem um bloqueio de teste antigo. A leitura segura é escopo, não imunidade: Parcial Relatado pela comunidade Se a sua Console ainda mostra o bloqueio, a sua Console é a autoridade sobre a sua conta. A decisão sobre o tipo de conta em si é assunto do artigo conta pessoal ou organizacional.

Um app em teste aberto é público ou aparece na busca?

A ideia de que "o teste aberto é só por convite" é uma das respostas erradas mais persistentes sobre o assunto, e dá para ver ela sendo corrigida nas mesmas discussões de fórum onde aparece. Vale dizer sem rodeios: um teste aberto não é um beta privado com um nome que soa público. Desconhecidos podem encontrar, entrar e usar o seu app sem nunca falar com você.

Isso tem uma consequência que as pessoas subestimam até estar no ar. A descoberta pública expõe o nome, o ícone, a descrição, as capturas de tela e a própria existência do seu app ao mercado em geral, e por isso o Google recomenda que o app e a ficha da loja estejam prontos para ficar visíveis no Google Play antes de você escolher essa faixa. Se concorrentes vão sair procurando é uma dedução prática dessa descoberta pública, não algo que o Google discuta; o fato documentado é simplesmente que a ficha pode ser encontrada.

Poder ser encontrado não significa aparecer na hora

O Google documenta que o teste pode ser encontrado. Ele não publica um prazo garantido para um app aparecer na busca, e a orientação de propagação que dá é modesta: depois de você publicar um teste pela primeira vez, o link pode levar algumas horas para ficar disponível, e mudanças publicadas depois podem levar várias horas. Fora isso, fichas reais de fato dão problema de vez em quando. Uma discussão de abril de 2026 na Google Play Developer Community relata uma ficha de teste aberto retornando 404 enquanto a faixa parecia ativa. Relatado pela comunidade Isso é um chamado de suporte, não um período de espera documentado, e a seção de diagnóstico separa as duas coisas.

Testadores abertos deixam notas ou avaliações públicas?

O medo que traz as pessoas até essa pergunta é bem específico e vale nomear: a primeira versão sai, os bugs iniciais são encontrados por usuários reais, e uma onda de avaliações de uma estrela limita para sempre a nota do app antes de ele ter público. Esse é um risco real de lançar em produção cedo demais. Não é um risco do teste aberto.

O que o feedback realmente faz

A afirmação que dá para fazer e a que é melhor evitar

A distinção importa se você está montando o seu plano de lançamento em cima dela. "O feedback do teste continua privado" é defensável e verificável. "Testadores beta nunca podem prejudicar a minha nota" é uma afirmação maior do que a documentação sustenta, e é a versão maior que uma hora vai pegar alguém de surpresa.

Você precisa de 1.000 testadores para o teste aberto?

Sempre que aparece um "o teste aberto exige 1.000 testadores", duas coisas diferentes estão sendo confundidas. Uma é um limite de configuração de um campo da Play Console. A outra é uma exigência de participação, que no teste aberto simplesmente não existe. Se você definir o limite em 1.000 e 37 pessoas aceitarem participar, você tem 37 testadores abertos e um teste aberto perfeitamente normal. O 37 é uma conta ilustrativa, não um patamar publicado pelo Google.

Vale separar isso também do número que realmente prende você. O 12 de "12 testadores por 14 dias contínuos" é um mínimo de verdade, e pertence ao teste fechado no caminho para o acesso de produção. O 1.000 daqui é um piso para um teto em uma faixa completamente diferente. Dois números, duas faixas, uma colisão muito comum.

Se o que você quer mesmo é um grupo pequeno e escolhido a dedo, o limite não é o seu problema e o teste aberto não é a sua faixa. Uma lista de convites controlada é exatamente para isso que serve o teste fechado, e a comparação entre as faixas mostra qual delas serve para cada objetivo.

Quando você realmente deve usar o teste aberto

Quatro casos em que a faixa compensa a exposição

• Lançar país por país

  O Google posiciona o teste aberto para testar um novo mercado e adaptar o app a ele antes de um lançamento mais amplo. Um beta público em um país dá diversidade real de aparelhos, condições reais de rede e feedback real de idioma que nenhuma lista de amigos convidados reproduz.

• Olhar as métricas antes de se comprometer

  O Google descreve o teste aberto como uma forma de reunir feedback quantitativo e qualitativo em larga escala, experimentar recursos de pré-lançamento e acompanhar métricas antes do lançamento. Se você precisa de números e não de opiniões, um grupo público maior costuma ser o jeito mais rápido de conseguir números estatisticamente úteis: retenção, conversão, carga do backend e diversidade de aparelhos se leem de um jeito bem diferente em escala do que em doze instalações convidadas.

• Verificações de estabilidade, retenção e monetização

  O Google Ads descreve o uso de um teste aberto para avaliar estabilidade, retenção, monetização e eficácia dos criativos de anúncio antes de um lançamento amplo. Se você pretende rodar uma campanha de app contra o teste aberto, o Google Ads também recomenda não limitar os downloads do teste aberto na Play Store, que é um segundo motivo para deixar a configuração de participantes em Unlimited.

• Uma última olhada em um recurso quase pronto

  A faixa foi feita para o estágio em que o build está perto de pronto e as dúvidas que restam são sobre o comportamento em escala, não sobre bugs óbvios. O feedback chega de forma privada, então nada do que você descobrir nessa etapa cai na sua nota pública.

Três motivos que não são motivos

• Para não ter que recrutar 12 testadores fechados. Para uma conta pessoal criada depois de 13 de novembro de 2023, isso simplesmente não funciona: a faixa está atrás do mesmo portão. É o motivo que traz a maioria das pessoas até esta página, e é a única resposta que não dá para suavizar.
• Para manter o app ou a ficha em segredo. Isso é o oposto do que a faixa faz. Se o seu motivo para testar em silêncio é que a ideia ainda não é pública, o teste aberto trabalha ativamente contra você.
• Para testar com um grupo pequeno e escolhido a dedo. Isso é teste fechado. Limitar um teste aberto no mínimo permitido de 1.000 não transforma ele em um teste privado; só define um teto que você nunca vai alcançar.

Do teste fechado ao teste aberto e à produção

O que realmente é levado adiante

"Promover" um build soa como um botão único que sobe o seu app um degrau na escada. O comportamento que o Google documenta é mais mecânico e mais útil de entender: a distribuição é decidida por usuário, pelo código de versão. Cada usuário recebe o maior código de versão compatível publicado em qualquer faixa para a qual ele seja elegível, e é por isso que um testador aberto que também é usuário de produção não continua no build de teste por fidelidade. Ele continua porque esse build tem o código de versão mais alto.

O mesmo modelo explica o rótulo Promoted. Uma faixa de teste aparece como Promoted quando os bundles ativos dela também estão ativos na faixa de fallback mais estável, ou seja, não há nada na faixa de teste que a produção já não tenha. É a descrição de um estado, não uma ação que você executa.

O teste aberto não aparece no Google Play? Verifique isto primeiro

Verifique quatro estados antes de tratar isso como um problema de indexação da Play Store ou um caso para o suporte. O app ainda não é elegível para a faixa, a versão foi configurada mas nunca foi lançada, o app não está no estado Published, ou não passou tempo suficiente desde a primeira publicação. É nesses quatro que moram as explicações comuns; tudo depois disso é realmente raro.

O que não concluir

Não existe nenhum número publicado de downloads que um app precise ter para aparecer na busca da Play Store. Essa afirmação circula como experiência pessoal em discussões de fórum e nenhuma fonte primária a sustenta. Também não existe um prazo garantido de indexação na busca: o Google documenta que o teste pode ser encontrado e dá orientações de propagação para links e mudanças, e para por aí. Se a ficha continuar quebrada bem depois da janela de propagação documentada, a resposta honesta é que você tem um chamado de suporte, não uma configuração esquecida.

Se o problema estiver do lado fechado e os seus testadores disserem que não conseguem ver o app de jeito nenhum, isso tem outro conjunto de causas: o artigo app indisponível para os testadores cobre as falhas de link e de elegibilidade, e adicionei 12 testadores e 0 participando cobre o problema de contagem que trava o relógio do acesso de produção.

Como a PrimeTestLab ajuda

O problema do recrutamento é o gargalo inteiro. A maioria dos desenvolvedores que lê isto sabe construir o app, subir o bundle, escrever a ficha da loja e responder ao formulário. O que trava essas pessoas por semanas é achar uma dúzia de gente com conta Google disposta a instalar alguma coisa, continuar participando e não desinstalar em silêncio no nono dia. Isso não é um problema de engenharia, e é exatamente por isso que ficar travado nele é tão frustrante.

Em 7.400+ apps, a taxa de aprovação do lado do testador se manteve em 99,9%, e esse número diz respeito ao teste rodar sem problemas, não à decisão do Google sobre o seu app. A aprovação depende de o seu app atender às políticas do Google, e nenhum serviço pode prometer isso. O que um teste gerenciado faz é tirar do seu colo o único requisito que é pura logística, para que os quatorze dias realmente passem. Se um teste concluído ainda assim terminar em recusa, a política de reembolso descreve o novo teste grátis e o reembolso total, e também as situações que ela não cobre.

Perguntas frequentes

Resumindo

Se é esse portão que está travando você de verdade, essa é justamente a parte que dá para delegar. Ver planos de preços →