Obtenha 12 Testers por 14 Dias e Publique Mais Rápido

Por que o Google exige 12 testers por 14 dias?

O requisito chegou no final de 2023, quando o Google apertou as regras para novas contas de desenvolvedor pessoal. O objetivo declarado é a qualidade: os apps devem chegar à loja pública após pessoas reais os terem usado genuinamente, não direto de uma máquina de compilação.

Para o Google, duas semanas de atividade ao vivo de testers filtra envios de baixo esforço e spam de forma muito mais confiável do que uma revisão de código poderia. Originalmente, a regra exigia 20 testers, mas o Google reduziu isso para 12 no final de 2024 para aliviar o fardo sobre desenvolvedores solo.

A mudança ocorre ao lado de outras verificações de identidade que o Google introduziu na mesma época, incluindo verificação por telefone e identidade para novas contas. Juntos, eles aumentaram o nível para publicar no Play, especialmente para desenvolvedores publicando seu primeiro app.

Os erros que reiniciam um relógio de 14 dias

A maioria dos testes fechados malsucedidos não é rejeitada pela qualidade do app — são rejeitados porque a contagem de 12 testers caiu silenciosamente abaixo da linha por um dia, ou a sequência não foi contínua. O Play Console não avisa quando isso acontece; apenas falha silenciosamente até você verificar a aba Testers.

Aqui está o que vemos com mais frequência quando um desenvolvedor vem a nós após uma tentativa fracassada:

• Os testers se inscrevem no primeiro dia e depois nunca mais abrem o app
• O teste é executado na faixa aberta ou interna em vez de uma faixa fechada
• Os países selecionados não correspondem aos países de produção pretendidos do app
• Um build no meio do teste causa uma falha na inicialização, então as sessões param abruptamente
• Um tester é trocado por um substituto, o que reinicia a contagem de 14 dias daquela vaga

O que acontece após o checkout

Projetamos o fluxo de pedidos em torno de uma ideia: sua parte deve levar minutos, não semanas. Assim que o pagamento é confirmado, um mecanismo de correspondência puxa testers cujos dispositivos, localidades e idade da conta se encaixam na categoria do seu app.

1. Hora 0–2: Seus 12+ testers são correspondidos e sua lista é enviada por e-mail, pronta para colar no Play Console.
2. Hora 2–6: Os testers aceitam seu convite e se inscrevem; o relógio de 14 dias começa.
3. Dia 1–14: Cada tester abre o app e registra uma sessão diariamente. Você pode assistir as contagens de inscrição serem atualizadas ao vivo no Play Console o tempo todo.
4. Dia 15: Seu relatório de engajamento é entregue, pronto para ser referenciado quando você solicitar acesso à produção.

Humanos reais vs. fazendas de bots

O Google olha além de uma simples contagem. Attestação de dispositivo, distribuição de IP, idade da conta e padrões de comportamento afetam se um lote de teste é lido como genuíno. Nossos testers estão espalhados por mais de 40 países e usam uma mistura real de OEMs Android — Samsung, Google Pixel, Xiaomi e mais — em contas com um histórico orgânico de atividade na Play Store.

Cada tester passou por uma revisão humana antes de se juntar ao grupo, e contas que mostram padrões suspeitos são removidas em vez de atribuídas a um novo pedido. Painéis de bots e fazendas de emuladores pegam um atalho aqui, e é o atalho que faz as contas de desenvolvedor serem sinalizadas.

O que chega à sua caixa de entrada no dia 15

Assim que a janela de 14 dias se fecha, você recebe um relatório de engajamento em PDF cobrindo os detalhes que o questionário do Google costuma perguntar: carimbos de data/hora de inscrição para cada tester, duração diária da sessão, modelo do dispositivo, versão do sistema operacional Android e país do tester.

A maioria dos desenvolvedores anexa um breve resumo deste relatório ao responder ao questionário de acesso à produção e mantém o arquivo completo à mão caso a equipe de revisão do Google faça perguntas sobre como os testes foram conduzidos.

Solicitando acesso à produção

Com o requisito de 14 dias cumprido, o botão "Solicitar acesso à produção" no Play Console é desbloqueado. Você responderá a um breve questionário sobre como você coletou feedback e o que, se algo, você mudou por causa disso — então o Google revisa o envio.

Os tempos de revisão variam, tipicamente alguns dias. Recomendamos esperar até que os 14 dias completos e mais de 12 inscrições sejam confirmados no Play Console antes de enviar; solicitar mesmo algumas horas antes é uma causa comum e evitável de rejeição que não tem nada a ver com a qualidade do app.

Esta regra se aplica à sua conta?

A regra de 12 testers tem como alvo específico contas de Desenvolvedor Pessoal criadas após 13 de novembro de 2023. Contas de organização, que exigem um número D-U-N-S durante o registro, estão isentas do teste fechado obrigatório.

Mesmo assim, muitas contas de organização escolhem realizar um teste fechado de qualquer forma. Dados de uso real antes do lançamento tendem a reduzir suspensões precoces causadas por falhas e dão uma primeira olhada em como o app se sai fora de um ambiente de desenvolvimento.

Como o relógio de 336 horas realmente conta

O relógio de 14 dias começa no momento em que seu 12º tester aceita o convite e se inscreve — o Play Console conta exatamente 336 horas contínuas a partir desse carimbo de data/hora, rastreado por tester, não por pedido.

Duas coisas o reiniciam: a contagem de inscritos caindo abaixo de 12 em qualquer momento, mesmo brevemente, ou remover um tester e substituí-lo por alguém novo, cujo próprio relógio então começa do zero. Você pode assistir a contagem em andamento a qualquer momento em Testers → Teste fechado no Play Console.

Como o Google revisa o próprio teste

Passar o limite de 12/14 desbloqueia o botão de inscrição, mas não é o único sinal que a revisão do Google pesa. Verificações automatizadas e, em alguns casos, revisores humanos olham a duração da sessão, taxa de falhas e taxa de desinstalação ao longo do período de teste.

Um app onde cada tester o abriu uma vez no primeiro dia e nunca voltou pode tecnicamente atender aos números 12/14, mas ser lido como de baixo engajamento por um revisor. É por isso que a atividade diária e espalhada por toda a janela importa mais do que simplesmente atingir a contagem mínima.

Rejeitado uma vez — o que muda na segunda vez

Leia o motivo da rejeição atentamente antes de fazer qualquer outra coisa. "Teste insuficiente" é um problema diferente de uma rejeição de conteúdo ou política, e cada um exige uma correção diferente. Reaplicar sem abordar a causa real apenas produz o mesmo resultado.

Se o motivo for teste insuficiente, o Play Console exige uma nova janela ininterrupta de 14 dias — não há crédito parcial por dias já concluídos. Se uma rejeição segue um teste que realizamos e a causa foi puramente o volume de testes, nós o refazemos sem custo extra.

Lista de verificação antes de convidar um único tester

Alguns minutos de configuração antes dos testers se inscreverem previne a maioria das falhas no Capítulo 3. Confirme cada um destes primeiro:

• A faixa de teste interno já foi revisada e aprovada pelo Google
• Uma faixa de teste fechado dedicada criada — não aberta, não interna
• Os países selecionados correspondem ou incluem os países de produção pretendidos
• Lista de e-mails de testers ou Google Group corretamente anexada à faixa fechada
• Listagem da loja — ícone, capturas de tela, descrição — completa o suficiente para que os testers não fiquem confusos

O que o Play Integrity realmente verifica

A API Play Integrity avalia cada instalação contra três vereditos: se o dispositivo atende ao padrão de integridade do Google, se o binário do app não foi modificado e se a conta está em boa situação e licenciada. Dispositivos com root, emuladores e APKs clonados normalmente falham nos dois primeiros.

Um único veredito falho dentro de um lote de testes pode lançar dúvidas sobre todo o grupo, e é por isso que testers em dispositivos físicos reais e não modificados importam mais do que contagem bruta. É também a principal razão pela qual painéis baratos baseados em bots colocam uma conta de desenvolvedor em risco em vez de protegê-la.

Respondendo ao formulário de acesso à produção do Google

O formulário de acesso à produção pede duas coisas em linguagem simples: como você coletou feedback durante os testes e o que você mudou como resultado. Respostas vagas e genéricas se destacam para revisores que leem centenas delas por dia.

Respostas específicas funcionam melhor — referencie uma observação real, como um dispositivo onde os tempos de carregamento estavam lentos e a correção que você lançou em resposta. Compartilhamos modelos construídos a partir de envios que passaram de primeira, que você pode adaptar às notas de teste do seu próprio app.

Termos do Play Console definidos

O vocabulário que o Play Console usa é específico — aqui estão os termos que mais aparecem neste guia.