Google Play pede mais testes para liberar a produção: o que o e-mail significa e como solicitar de novo (2026)

O e-mail "More testing required to access Google Play production" do Google Play significa que o Google recusou sua solicitação de acesso à produção. Não é uma advertência por violação de política e não suspende seu app. Mas custa tempo: você precisa de mais um bloco de 14 dias de teste fechado antes de solicitar de novo. Este guia explica cada motivo do e-mail, lista o que mudar durante os 14 dias extras e mostra como reescrever o questionário para que a segunda solicitação seja a última. Se você ainda não começou um teste fechado, comece pelo nosso plano de teste com 12 testadores por 14 dias.

O que significa "More testing required to access Google Play production"?

Significa que um revisor do Google leu sua solicitação de acesso à produção (Apply for production) e concluiu que o teste fechado não gerou evidências suficientes de que o app está pronto para o público. A produção e a pré-inscrição continuam bloqueadas até você fazer mais testes e solicitar de novo.

Em novembro de 2026, os requisitos de teste de apps do Google se aplicam a contas pessoais de desenvolvedor criadas depois de 13 de novembro de 2023. Essas contas precisam fazer "um teste fechado do app com no mínimo 12 testadores inscritos continuamente por pelo menos 14 dias". Cumprir esses números só permite que você faça a solicitação. A solicitação em si é analisada, e o Google cita dois motivos pelos quais você pode precisar de mais testes: "ter menos de 12 testadores inscritos ou engajamento insuficiente dos testadores durante o período de teste". O Google diz que a análise "costuma levar sete dias ou menos, mas ocasionalmente pode demorar mais", e o proprietário da conta recebe a decisão por e-mail.

O que significa cada motivo do e-mail de recusa?

Cada linha do e-mail aponta uma lacuna específica: testadores que não usaram o app de verdade, um teste sem mudanças visíveis em resposta ao feedback ou respostas do questionário vagas demais para avaliar. O e-mail pode listar um, dois ou os três motivos.

Desenvolvedores que publicaram o e-mail citam os mesmos motivos: "Testers were not engaged with your app during your closed test" (os testadores não se engajaram com o app durante o teste fechado), "You didn't follow testing best practices, which may include gathering and acting on user feedback through updates to your app" (você não seguiu as boas práticas de teste, o que pode incluir coletar feedback dos usuários e agir sobre ele com atualizações do app) e respostas sobre o app, o teste fechado ou a prontidão para produção que estavam "incomplete or insufficient" (incompletas ou insuficientes). A instrução final é: "Antes de solicitar de novo, teste seu app usando teste fechado por mais 14 dias com testadores reais." O Google não divulga como mede o engajamento, então a tabela relaciona cada motivo ao texto correspondente na própria página de ajuda do Google e a uma correção.

O que fazer logo depois da recusa?

Mantenha o teste fechado ativo, peça aos testadores que continuem inscritos e publique um novo build na faixa fechada em poucos dias. A página do Google diz que, se você não for aprovado, "talvez seja preciso continuar executando o teste fechado", então desmontar o teste e começar outro joga fora sua base de testadores.

1. Não remova a faixa fechada nem sua lista de testadores. O Google avisa que "se um testador cancelar a inscrição e se inscrever de novo depois, os 14 dias precisam ser consecutivos", então qualquer testador que sair agora reinicia a própria contagem.
2. Mande mensagem para todos os testadores. Explique que o teste continua por mais 14 dias, que eles precisam continuar inscritos e o que você quer que testem nesta rodada.
3. Confira a contagem de testadores no Play Console. Substitua quem nunca instalou o app por pessoas que vão realmente usá-lo. Amigos que instalam e nunca abrem o app são a causa habitual do motivo "não se engajaram".
4. Defina um único canal de feedback. O Google sugere um chat em grupo; um formulário compartilhado também funciona. Seja qual for a escolha, salve cada mensagem com a data.
5. Escreva uma lista de tarefas que cubra cada recurso principal: cadastro, a ação central, configurações, compras (com testadores de licença se o app tiver faturamento) e qualquer fluxo offline ou de notificações.
6. Publique uma atualização na faixa fechada na primeira semana que corrija algo relatado por um testador e cite a correção nas notas da versão. Planeje uma segunda atualização antes do dia 14.
7. Gere o relatório de pré-lançamento e corrija as falhas e os alertas de acessibilidade que ele encontrar.
8. Antes de solicitar de novo, confira se a classificação de conteúdo, o público-alvo e o formulário de Segurança dos dados estão corretos. Se o app exigir login, inclua "credenciais de login válidas e funcionando", como a página do Google pede.

Se o seu app também precisa atualizar o SDK de destino antes de ir ao ar, faça isso dentro da mesma janela. Nosso guia do nível de API 36 cobre o prazo de 1º de novembro de 2026.

Como reescrever as respostas do questionário de acesso à produção?

Troque afirmações genéricas por detalhes: quais recursos os testadores usaram, quantos relatos chegaram, como você os coletou, qual versão corrigiu o quê e que evidências mostraram que o app estava estável. Cada resposta deve ser algo que só um desenvolvedor que fez um teste real conseguiria escrever.

Você abre o formulário no Painel do Play Console, em Solicitar acesso à produção (Apply for production). Ele tem três partes: seu teste fechado, seu app e a prontidão para produção. O progresso se perde se você sair de uma parte antes de clicar em Próxima, então rascunhe as respostas em um documento antes. Um desenvolvedor no itch.io relatou "um limite de 300 caracteres para cada resposta", outro motivo para rascunhar e enxugar com antecedência. As respostas da Parte 2 não são exibidas publicamente e não afetam a visibilidade do seu app.

Exemplo prático para um app hipotético de acompanhamento de hábitos. As respostas fracas são típicas de solicitações que voltam com "incompletas ou insuficientes":

O que outros desenvolvedores relataram depois de uma recusa por "mais testes"?

Os relatos públicos seguem um padrão: testadores que se inscreveram mas nunca enviaram feedback levaram à recusa, enquanto um grupo pequeno que enviou feedback e viu o app mudar foi aprovado. A quantidade de testadores importou menos do que a evidência de uso.

• Na comunidade do MIT App Inventor, o desenvolvedor shigeki_suzuki relatou em julho de 2024 que seu app Season Clock chegou a 20 testadores por 14 dias por meio de um app de troca de testadores e depois recebeu "More testing required to access Google Play production" com "Testers were not engaged with your app during your closed test". Ele escreveu que não sabia quem eram os testadores e não tinha recebido nenhum feedback, então não conseguiu descrever como foi o teste nem o que mudou. Teve que repetir o teste.
• No fórum da Adalo, o usuário siang32195 relatou a mesma mensagem "More testing required" em agosto de 2024 depois de usar testadores recrutados. Ele perguntou como verificar se os testadores realmente tinham usado o app. A resposta sugeriu ferramentas de registro de tempo ou um relatório escrito listando os cenários de teste que cada testador cobriu. A discussão não diz se a segunda solicitação deu certo.
• Um desenvolvedor de jogos independente escrevendo no itch.io tinha "mal e mal 12 testadores", mas escreveu que tinha "feito várias atualizações no jogo" e "registrado tudo o que pude das minhas interações com os testadores". Ele usou esse registro na solicitação e relatou: "Em até 36 horas depois de enviar a solicitação, recebi o acesso à produção."

A comparação: 20 testadores sem histórico de feedback foram recusados, enquanto 12 testadores com um histórico documentado de feedback e atualizações foram aprovados. Solicite de novo quando suas anotações conseguirem responder cada campo do questionário com detalhes, e não assim que a contagem chegar a 14 dias.

Quando clicar em Solicitar acesso à produção de novo?

Solicite de novo quando pelo menos 12 testadores estiverem inscritos por mais 14 dias consecutivos e você tiver publicado atualizações motivadas por feedback nesse período. A página do Google não menciona um prazo de espera, mas solicitar com as mesmas evidências provavelmente vai trazer a mesma resposta.

• Pelo menos 12 testadores inscritos, sem interrupções na inscrição, por mais 14 dias consecutivos (mire em 15 ou mais como margem)
• Pelo menos duas versões na faixa fechada desde a recusa, cada uma com notas da versão citando uma correção relatada por testadores
• Um registro de feedback com datas, com contagem por tipo (bugs, UX, pedidos) e como cada item foi coletado
• Testadores que usaram todos os recursos principais, incluindo login, compras e notificações quando for o caso
• Um relatório de pré-lançamento sem falhas pendentes
• Classificação de conteúdo, público-alvo e formulário de Segurança dos dados corretos, além de credenciais de login funcionando para o revisor
• Respostas do questionário rascunhadas em um documento, com recursos, números e versões

A página do Google também avisa que "enviar apps fora de conformidade esperando que os revisores identifiquem os problemas leva a recusas, atrasos na análise e processos de recurso mais longos", então corrija qualquer problema de política antes de solicitar, e não depois. Se preferir entregar a configuração do Play Console, o plano de teste fechado e a solicitação para outra pessoa, nosso serviço de envio para as lojas cobre as duas lojas por US$ 599. As taxas das contas de desenvolvedor são cobradas à parte.