Resposta rápida
Escreva as respostas a partir dos seus próprios registros de recrutamento, testes, feedback, mudanças e prontidão. Use os exemplos abaixo como estrutura de redação, troque todos os detalhes factuais e siga o texto e o limite de caracteres que aparecem no formulário do seu Play Console.
O formulário pergunta sobre o teste que você acabou de fazer, sobre o app que você criou e sobre a sua decisão de publicá-lo. Esta página percorre campo por campo, mostra um rascunho pronto e explica o que escrever quando a sua evidência é escassa, é qualitativa ou não gerou nenhuma mudança de código.
O que é o formulário de acesso de produção?
Quando o seu teste fechado atende aos critérios, o Play Console mostra “Solicitar o acesso de produção” no painel do seu app. Esse painel lista os critérios que ainda faltam e traz um link Visualizar perguntas, para você ler o formulário antes de começar. O Google pergunta em três seções:
O Google descreve o objetivo da seção do teste fechado como confirmar que os apps foram testados de forma satisfatória antes da publicação. A seção 2 é a parte mais leve: o Google afirma que essas respostas não aparecem no Google Play e não afetam o acesso aos recursos do Play Console.
O que o Google publica
- A análise costuma levar 7 dias ou menos e pode demorar mais.
- O Google pode pedir que você continue testando se você não tiver 12 testadores qualificados ou se os testadores não tiverem se engajado com o app.
- As respostas da seção 2 não são publicadas e não afetam o acesso aos recursos.
- Sair do formulário sem percorrê-lo até o fim pode descartar as respostas não salvas: use Avançar entre as seções e Solicitar no final.
Fonte: Ajuda do Play Console, requisitos de teste para contas pessoais de desenvolvedor.
Esta página cobre nove perguntas do pedido inicial, mais uma pergunta de nova solicitação relatada por desenvolvedores que receberam o pedido de continuar testando. O Google não publica uma lista fixa, e o texto relatado, os tipos de campo e as perguntas que aparecem variam de conta para conta. Siga o seu próprio formulário.
Todo exemplo aqui tem menos de 300 caracteres e mostra a própria contagem. Alguns desenvolvedores relatam um limite perto desse número, mas não foi possível verificar nenhum limite universal em vigor, então quem manda é o contador do seu formulário. Não há evidência publicada ligando o tamanho da resposta ao resultado.
Quais evidências você deve preparar?
Faça isto uma vez e o formulário deixa de ser um problema de redação. Reúna estas três coisas antes de abri-lo. Tudo nesta página é montado a partir delas.
Os números que o formulário vai pedir, tirados das informações de elegibilidade do Play Console e dos seus próprios registros, para que os dois batam com o que você escrever.
- Quantos testadores estavam participando e em quais datas.
- Se a participação foi contínua nos últimos 14 dias, sem nenhuma interrupção.
- Em qual versão cada testador terminou o teste.
Desinstalar não é sair do teste. Quem apaga o app continua participando; sair é uma ação deliberada, feita pelo link do teste ou pela seção de versão beta do app na Play Store (Sair do programa beta de um app). Ou seja, o número de instalações não prova que houve teste nem que ele parou.
Atividades, não adjetivos. Anote os fluxos que eles concluíram e como você sabe disso.
- Quais fluxos principais foram usados: cadastro, a tarefa central, compartilhamento, configurações, pagamento.
- Com que frequência, mais ou menos, o app foi aberto e em que período.
- Onde as pessoas travaram e, se você souber, em quais aparelhos ou versões do Android.
Diga de onde vem cada afirmação. Uma contagem baseada no relato dos testadores é diferente de uma contagem registrada por analytics, mesmo quando as duas aparecem como números. As duas servem; deixe claro qual delas você tem.
O Google indica aos desenvolvedores a página de feedback de teste do Play Console e recomenda manter um registro. Uma linha por constatação já basta:
- Onde o feedback chegou (feedback do Play Console, formulário no app, chat, e-mail).
- O que você lançou em resposta e em qual versão.
- Como você confirmou que funcionou e quais constatações continuam em aberto.
Um registro que responde a quatro das nove perguntas
Três colunas bastam. As linhas abaixo pertencem ao app fictício apresentado na próxima seção; as suas não vão se parecer em nada com elas, e é justamente essa a ideia.
| O que o teste encontrou | O que foi lançado | Como foi verificado |
|---|---|---|
| Os lembretes de turno não disparavam depois que a escala era editada. | Versão 1.4.1: reagendamento dos lembretes corrigido após a edição da escala. | Os dois testadores que relataram o problema confirmaram que os lembretes chegaram nos dois turnos seguintes. |
| A publicação da escala falhava em conexões lentas e o rascunho se perdia. | Versão 1.4.2: o rascunho fica salvo no aparelho e a publicação é repetida até dar certo. | Testado de novo com a conexão limitada, antes e depois; o rascunho se manteve. |
| A visualização semanal ficava apertada em telas pequenas. | Não lançado. Programado para depois do lançamento. | Em aberto. Citado como item pendente na resposta sobre prontidão, em vez de apresentado como resolvido. |
E se você não tiver analytics detalhado?
Se você não coletou analytics de sessão, ainda assim dá para responder a todas as perguntas. O que não dá é transformar uma impressão em medição. Diga o que você sabe e deixe claro como você sabe. “Dez dos doze testadores me disseram que criaram pelo menos uma escala; eu não tinha analytics de sessão” é uma frase utilizável e verificável. Uma duração média de sessão inventada não é.
O mesmo vale para o relatório de pré-lançamento: o Google o descreve como um teste automatizado nos aparelhos dele, com limites de cobertura (Usar o relatório de pré-lançamento para identificar problemas). Ele comprova uma varredura automatizada, não um teste feito por pessoas.
Se o Android vitals não mostrar travamentos
Um painel vazio não prova que não houve nenhum travamento. O Android vitals depende de dados de diagnóstico qualificados, e o Google observa que uma tela vazia pode significar dados insuficientes para os filtros que você selecionou (Android vitals). Se os dados forem escassos, relate essa limitação.
Escreva as respostas em outro lugar primeiro
O Google avisa que sair do formulário sem clicar em Avançar em cada seção e em Solicitar no final pode descartar o seu trabalho. Escreva as respostas em um documento, compare uma com a outra e só então cole tudo lá.
Ainda precisa de testadores?
Se você já concluiu o teste, use os exemplos abaixo para preparar as respostas com base nos seus próprios registros e confira cada resposta com o que realmente aconteceu. Se ainda precisa de testadores, compare as opções de suporte de teste: a PrimeTestLab fornece as respostas do formulário depois do teste, e você as confere e envia a solicitação.
Como usar estes exemplos de resposta
Todos os fatos de todos os exemplos abaixo são inventados. Todos descrevem um mesmo app fictício, para você ver como um único registro de teste vira nove respostas coerentes entre si. Nenhum deles é uma resposta pronta para enviar sobre o seu app, e nenhum vira isso só por ser encurtado.
Troque cada nome, número, data, recurso e constatação pelos seus antes de usar qualquer coisa daqui. Uma resposta que ainda diz “Shiftly”, ou que ainda afirma doze testadores em catorze dias quando não foi isso que aconteceu, descreve o teste de outra pessoa.
Qual variação escolher?
Os rascunhos padrão seguem todos o teste fictício do Shiftly. As abas alternativas descrevem outras circunstâncias: outro método de recrutamento, evidências mais escassas, um tipo diferente de app. Escolha a que corresponde ao seu teste e depois faça as respostas relacionadas combinarem entre si. Uma resposta que diz que nada mudou não pode ficar ao lado de respostas de feedback e de prontidão que afirmam ter lançado correções, e a aba do jogo é outro jogo fictício.
Como ler um rascunho
- O texto marcado assim é um dado que você precisa trocar.
- Copiar como modelo troca cada um deles por uma instrução entre colchetes, nunca por uma frase pronta.
- As explicações ficam fora do painel do rascunho, então você não cola um comentário editorial dentro do formulário.
- A contagem de caracteres mede o exemplo, não o texto que você vai colocar no lugar.
Exemplo ilustrativo, não é um app real
ShiftlyUm app fictício de escalas de turno para pequenos comércios e cafés, usado ao longo desta página só para manter as nove respostas coerentes. Não é um cliente, não é um estudo de caso e nenhum resultado é atribuído a ele.
- Teste fechado 12 testadores, 14 dias contínuos
- Fluxos principais Cadastro, montar a escala da semana, convidar um colega, publicar, receber o lembrete de turno
- Versões lançadas no teste 1.4.1 e 1.4.2
- Item em aberto Visualização semanal apertada em telas pequenas
Parte 1: sobre o seu teste fechado
Esta seção pede que você descreva o recrutamento, a atividade e o feedback. Mantenha as respostas coerentes com as informações de elegibilidade do Play Console e com os seus próprios registros de teste, e explique as atividades, os retornos e as verificações que nenhuma métrica de painel captura.
Como você recrutou usuários para o seu teste fechado?
O Google quer saber de onde vieram os seus testadores. Diga a origem que você realmente usou e quem conduziu o teste. Variar as origens é uma boa prática, não uma regra contra usar uma só, então um único canal verdadeiro vale mais do que uma lista inventada.
O que este campo precisa
- O canal ou os canais que você realmente usou.
- Quem são os testadores em relação ao público do seu app.
- Quem definiu os cenários, leu o feedback e lançou as mudanças.
Rascunho de exemplo (fictício)
Recrutei 12 testadores em minha própria rede: cinco colegas de um coworking, quatro amigos que montam escalas em lojas e três de um fórum de testes. Todos entraram em dois dias e ficaram participando os 14 dias inteiros. Eu mesmo defini os cenários e li o feedback.
Cópia indisponível. Selecione e copie o modelo abaixo.
Rascunho de exemplo (fictício)
Recrutei 12 testadores por meio de um serviço pago de testes. Eu escolhi os cenários, li o feedback no Play Console e nos relatórios do serviço, lancei duas atualizações no teste e pedi a quem relatou que confirmasse a correção.
Cópia indisponível. Selecione e copie o modelo abaixo.
Rascunho de exemplo (fictício)
Todos os 12 testadores vieram de uma única origem: um grupo de donos de lojas independentes do qual eu já fazia parte. São exatamente as pessoas para quem o app foi feito. Convidei cada um diretamente, em vez de divulgar um link público do teste.
Cópia indisponível. Selecione e copie o modelo abaixo.
Uma versão mais fraca e o que ela deixa de fora
“Encontrei testadores na internet.”
Não cita canal nenhum, nenhuma relação com o seu público e ninguém que tenha conduzido o teste.
Nenhuma orientação publicada sugere que citar um serviço contratado afete o resultado. O que importa é que o resto do formulário combine com isso: se um serviço recrutou os testadores, diga quem definiu os cenários, leu o feedback, fez as mudanças e as verificou.
Quão fácil foi recrutar testadores?
Uma escala que vai de muito difícil a muito fácil. Escolha a opção que corresponde à sua experiência. Nenhuma orientação publicada indica uma opção preferida. As linhas abaixo são ilustrações soltas, não critérios: recrutar pode ser difícil ou fácil por motivos que nenhuma delas cobre.
- Muito difícil Você não chegou a 12 e o teste atrasou ou travou.
- Difícil Foi preciso insistir, ou fazer várias tentativas ao longo de muito tempo.
- Nem fácil nem difícil Deu algum trabalho e levou mais ou menos o tempo que você esperava.
- Fácil Um ou dois convites já preencheram a lista.
- Muito fácil Você teve mais voluntários do que vagas.
Nenhuma opção aqui é recomendada. O texto e a quantidade de alternativas podem ser diferentes do que aparece acima; leia o seu próprio formulário.
Descreva o engajamento que você recebeu dos testadores
Os exemplos do próprio Google aqui falam do uso dos recursos e de se esse uso se parece com o uso real em produção. “Muito engajados” não descreve nada que alguém consiga visualizar. Informe os fluxos, o período, o padrão de uso e de onde vêm os seus números.
O que este campo precisa
- Quantos testadores e em que período.
- De dois a quatro fluxos que eles realmente concluíram, pelo nome.
- O padrão de uso e a origem dos números.
Rascunho de exemplo (fictício)
Em 14 dias, 12 testadores criaram 31 escalas semanais; todos concluíram o cadastro, nove convidaram um colega e sete receberam lembrete. Quem tem várias lojas abria o app quase todo dia; quem tem uma, uma vez por semana. Os números vêm do registro de eventos no app.
Cópia indisponível. Selecione e copie o modelo abaixo.
Rascunho de exemplo (fictício)
Não tive analytics de sessão durante o teste. Dez dos doze testadores me disseram que criaram pelo menos uma escala e seis convidaram um colega. Acompanhei dois deles fazendo o cadastro em uma tela compartilhada. Não consigo informar o número de sessões.
Cópia indisponível. Selecione e copie o modelo abaixo.
Uma versão mais fraca e o que ela deixa de fora
“Os testadores foram ativos e usaram o app.”
Sem número, sem período, sem nenhum fluxo citado e sem fonte para nada disso.
Faça um resumo do feedback que você recebeu
O Google pergunta o que o feedback dizia e como você o coletou. Informe o canal, os temas que realmente apareceram e o que você fez sobre cada um, inclusive o que ficou sem fazer. Encaixar várias constatações em um campo curto é a parte que dá trabalho de edição.
O que este campo precisa
- Onde o feedback chegou.
- Os temas que de fato apareceram, sejam quantos forem.
- Quais deles você já lançou e quais continuam em aberto.
Rascunho de exemplo (fictício)
O feedback chegou pelo feedback de teste do Play Console e por um grupo de mensagens. Os temas foram lembretes que não disparavam após editar a escala, falha ao publicar em conexão lenta e visualização semanal apertada. Os dois primeiros foram corrigidos e lançados; o terceiro segue em aberto.
Cópia indisponível. Selecione e copie o modelo abaixo.
Uma versão mais fraca e o que ela deixa de fora
“O feedback foi positivo.”
Não dá canal, nem tema, nem resposta, que são justamente as três coisas que o campo pede.
Se o feedback foi mesmo todo positivo, diga isso e diga sobre o que ele tratava. Um defeito inventado também precisa ficar coerente com a Q8 e a Q9.
Faltam testadores que fiquem participando por 14 dias sem interrupção?
A PrimeTestLab fornece 12 testadores pré-qualificados a partir de US$ 19,99, com início em 4-6 horas.
Parte 2: sobre o seu app ou jogo
O Google afirma que estas respostas não aparecem no Google Play e não afetam o seu acesso aos recursos do Play Console. Escreva de forma direta. Isto não é texto de loja, e não há nada a ganhar vendendo o app aqui.
Qual é o público-alvo do seu app?
O Google pede que você seja específico. “Todo mundo” não descreve ninguém. Diga quem são essas pessoas, que problema elas têm e quando elas recorrem ao app. Se você realmente tem dois tipos de usuário, cite os dois.
O que este campo precisa
- Quem são: função, situação ou faixa etária, se isso for mesmo relevante.
- O problema que elas têm sem o seu app.
- Quando e com que frequência elas usam o app.
Rascunho de exemplo (fictício)
Shiftly é para donos e gerentes de lojas e cafés com 3 a 20 funcionários que hoje montam a escala no papel ou em um app de notas. Eles usam o app uma vez por semana, ao planejar a semana seguinte, e em momentos rápidos quando alguém pede troca de turno.
Cópia indisponível. Selecione e copie o modelo abaixo.
Uma versão mais fraca e o que ela deixa de fora
“Todo mundo.”
Não cita usuário, nem problema, nem ocasião, e quase nunca é verdade.
Descreva como o seu app gera valor para os usuários
Comece pelo resultado e só então cite os dois ou três recursos que o produzem. Em um jogo, o valor é a experiência: o ciclo de jogo, o que o torna diferente, quanto dura uma partida e por que alguém volta.
O que este campo precisa
- O resultado, em uma frase, antes de qualquer lista de recursos.
- Dois ou três recursos que produzem esse resultado.
- Em um jogo: o ciclo, o elemento que o diferencia, a duração da partida.
Rascunho de exemplo (fictício)
Shiftly permite que gerentes de loja reaproveitem a escala da semana anterior, publiquem os turnos para a equipe e enviem um lembrete antes de cada turno. A equipe pede trocas pelo app, em vez de por mensagem.
Cópia indisponível. Selecione e copie o modelo abaixo.
Rascunho de exemplo (fictício)
Os jogadores limpam o tabuleiro encadeando combinações de cores em 90 segundos. Cada tabuleiro concluído reescreve o próximo, então nenhuma partida se repete. Uma partida dura cerca de três minutos, e os jogadores voltam pelo tabuleiro diário.
Cópia indisponível. Selecione e copie o modelo abaixo.
Uma versão mais fraca e o que ela deixa de fora
“Meu app é útil e tem bons recursos.”
Nenhum resultado, nenhum recurso e nenhum usuário, em um campo que o Google nem publica.
A aba Jogo é um segundo exemplo fictício, não o Shiftly. Se você usá-la, o resto das suas respostas descreve o seu jogo, não um app de escalas.
Quantas instalações você espera no primeiro ano?
O Google diz que uma estimativa aproximada basta e que as faixas são propositalmente amplas. Escolha a faixa que o seu público e a sua estimativa de lançamento sustentam. Nenhuma orientação publicada indica uma faixa preferida, e não há base para o conselho comum de ficar com a faixa do meio.
- 0 a 10 mil
- 10 mil a 100 mil
- 100 mil a 1 milhão
- Mais de 1 milhão
- Não sei É uma opção de verdade, e mais defensável do que um número inventado.
Nenhuma opção aqui é recomendada, e nenhuma dessas faixas diz coisa alguma sobre o seu app. Os rótulos das faixas e o texto variam; leia o seu próprio formulário.
Parte 3: prontidão para a produção
Esta seção pergunta o que o teste produziu e por que você decidiu publicar. As duas respostas devem soar como conclusões tiradas do registro que você montou antes, e não como afirmações novas que aparecem aqui pela primeira vez.
Que mudanças você fez com base no seu teste fechado?
Descreva as mudanças que você realmente fez e como você as verificou. A orientação publicada não define nenhuma fórmula de pontuação para este campo nem um número mínimo de atualizações. Isso não é o mesmo que dizer que a resposta não tem efeito, e não justifica deixar de lado um problema conhecido que bloqueie o app ou fira uma política. Separe o que já está pronto do que ainda está planejado.
O que este campo precisa
- O que o teste encontrou, nas suas palavras.
- O que você lançou em resposta, com o número da versão, se tiver.
- Como você verificou e o que continua em aberto.
Rascunho de exemplo (fictício)
Duas versões durante o teste. A 1.4.1 corrigiu o reagendamento dos lembretes após editar a escala; a 1.4.2 corrigiu a publicação em conexão lenta. Quem relatou a falha confirmou a correção, e retestei a publicação com a conexão limitada. A visualização semanal apertada segue em aberto.
Cópia indisponível. Selecione e copie o modelo abaixo.
Rascunho de exemplo (fictício)
Não lancei mudanças neste teste. Os testadores verificaram o cadastro no Android 10, a publicação em conexão lenta e os lembretes em três aparelhos. Resultado: sem falhas relatadas e sem travamentos no Android vitals em um período com dados suficientes. O layout em telas pequenas não foi testado.
Cópia indisponível. Selecione e copie o modelo abaixo.
Uma versão mais fraca e o que ela deixa de fora
“Melhoramos o app.”
Não cita nenhuma constatação, nenhuma versão e nenhuma verificação, então não dá para conciliar com a sua resposta sobre feedback.
E se você não fez nenhuma mudança?
A orientação não prescreve um número de atualizações, e um app que não mudou não é automaticamente um pedido fraco. O que enfraquece uma resposta é um teste sem explicação. Use a aba Sem mudanças lançadas acima: quais fluxos e condições foram verificados, quais foram os resultados e de onde eles vieram, e o que ficou sem solução. Não invente um defeito só para ter uma correção a relatar.
Como você decidiu que o seu app está pronto para a produção?
O Google está pedindo os seus critérios de decisão, não a sua confiança. Cite as duas ou três coisas que você analisou e a evidência por trás de cada uma. Tudo isso já deve ter aparecido antes no formulário, com o mesmo histórico de verificação.
O que este campo precisa
- Os critérios que você usou, apresentados como critérios.
- A evidência por trás de cada um deles.
- Os itens em aberto e por que eles não impedem o lançamento.
Rascunho de exemplo (fictício)
Três critérios. A correção dos lembretes foi confirmada pelos testadores afetados. Retestei a publicação da escala com a conexão limitada depois da 1.4.2. A visualização semanal apertada continua em aberto; é estética, e os fluxos principais testados funcionam.
Cópia indisponível. Selecione e copie o modelo abaixo.
Uma versão mais fraca e o que ela deixa de fora
“Eu senti que o app estava pronto.”
Uma sensação não é um critério, então não há aqui nada com que concordar ou discordar.
Erros comuns nas respostas
Nada disso é uma regra publicada pelo Google. São os padrões que fazem uma resposta comunicar menos do que o desenvolvedor que a escreveu pretendia.
“Muito engajados”, “muito positivo”, “testado a fundo”. Cada um ocupa espaço em um campo curto sem citar um fluxo, um número ou um período.
“Nenhum problema foi encontrado” em um campo e “corrigi vários erros” no seguinte. As duas coisas não podem ser verdade, e quem lê não tem como saber qual delas é.
Se você relata um feedback, diga onde ele chegou: feedback de teste do Play Console, formulário no app, grupo de mensagens, e-mail. Sem isso, o resumo fica sem fonte.
Um exemplo colado que ainda descreve o app, o público ou o erro de outra pessoa não é uma descrição do seu teste. Todo modelo tem esse mesmo ponto fraco, inclusive os desta página.
Uma porcentagem inventada para parecer rigorosa é uma afirmação que você não consegue sustentar. Uma contagem vinda do relato dos testadores serve muito bem; basta dizer que é isso que ela é.
Diga quais correções já foram lançadas e quais estão programadas. Apresentar um plano como versão lançada é desmentido pelo seu próprio histórico de versões.
Escolher a opção que soa mais forte em vez da que realmente aconteceu coloca a sua lista suspensa em conflito com o seu texto livre, e nenhuma orientação publicada indica uma escolha preferida.
Confira as suas respostas antes de enviar
O formulário é lido como um documento único. O que o enfraquece quase nunca é uma frase ruim, e sim duas frases que não combinam. Faça esta revisão com as nove respostas lado a lado.
Nada nesta lista prevê uma decisão. É a revisão que impede o seu formulário de se contradizer.
O que acontece depois que você envia o pedido?
Vale separar quatro desfechos, porque dois deles são confundidos o tempo todo. Uma análise ainda em andamento não é um pedido de mais testes, e acesso concedido não é app publicado.
Acompanhe a análise
Análise em andamentoO Google afirma que a análise costuma levar 7 dias ou menos e pode demorar mais. Acompanhe o Play Console e o e-mail da conta, e responda a qualquer coisa que o Google pedir. Uma espera longa, por si só, não é motivo para reenviar o pedido nem para recomeçar o teste.
Falta mais um passo
Acesso de produção concedidoTer acesso e ter o app no ar são coisas diferentes. Você ainda precisa preparar e lançar uma versão de produção, que passa pela própria análise. Veja o fluxo de lançamento do Google e o nosso guia sobre os prazos de análise do acesso de produção e das versões.
Leia a mensagem recebida
Mais testes necessáriosÉ uma decisão sobre o seu teste, não só sobre a forma como você escreveu. Orientação completa abaixo.
Problema no app, não no texto
O revisor não conseguiu abrir o appSe o seu app fica atrás de um login ou tem algum outro acesso restrito, o revisor precisa de credenciais que funcionem. Informe-as em dados de acesso para análise. Nenhuma resposta do formulário substitui esse acesso.
Se o Google pedir que você continue testando
Não reenvie o mesmo formulário e não presuma que o problema foi a sua redação. Trabalhe nesta ordem.
A notificação costuma indicar um motivo: menos de 12 testadores qualificados, uma participação que foi interrompida durante os 14 dias ou testadores sem engajamento. Trate essa mensagem como mais confiável do que qualquer guia geral, inclusive este.
Se faltaram testadores, ou se alguém deixou de participar, volte a ter 12 testadores qualificados com histórico recente sem interrupções antes de solicitar de novo, o que, no caso de testadores novos, significa mais 14 dias completos. Reescrever respostas sobre um registro de testadores que não mudou não muda as informações de elegibilidade.
Atualize os fatos que mudaram e esclareça qualquer resposta que tenha ficado incompleta ou ambígua: uma resposta pode deixar de comunicar uma evidência que você já tinha. O que reescrever não resolve é um problema de fundo no teste. Um segundo teste pode gerar novas observações, feedback, mudanças ou verificações, mas nada disso é garantido e não é obrigatório lançar uma nova versão.
O Google exige que os 14 dias consecutivos mais recentes tenham testadores qualificados, então nunca solicite com menos de 12. Fora isso, algumas mensagens de recusa indicam um prazo adicional e outras não indicam nenhum: o Google não publica um intervalo universal para uma nova solicitação. O nosso guia sobre como solicitar de novo depois de uma recusa por “mais testes necessários” cobre os dois casos, inclusive por que pedir aos testadores que saiam e entrem de novo destrói o histórico que você já tem.
Se o que você quer entender é o que deu errado no teste em si, e não no formulário, comece por como resolver uma recusa no teste fechado.
O que você fez de diferente desta vez?
Relatada por desenvolvedores que solicitaram de novo depois de receber o pedido de continuar testando. O texto relatado varia, e nem toda conta relata tê-la visto, então confira o seu próprio formulário em vez de presumir que ela vai ou não aparecer.
Diga o que está diferente no registro, não o que está diferente na sua postura. Se o segundo teste foi igual ao primeiro, é isso que precisa mudar antes de solicitar de novo.
O que este campo precisa
- O que mudou no próprio teste.
- O que isso produziu: constatações, versões lançadas, confirmações.
- Como a evidência atual responde à decisão anterior.
Rascunho de exemplo (fictício)
Desde o último pedido, eu fiz outro teste de 14 dias com 12 testadores e registrei o que cada um deles fez. Apareceram duas falhas nos lembretes, corrigidas na 1.4.3 e confirmadas por quem as relatou. Estas respostas descrevem esse teste e essas versões.
Cópia indisponível. Selecione e copie o modelo abaixo.
Uma versão mais fraca e o que ela deixa de fora
“Desta vez eu me concentrei em coletar e aplicar o feedback.”
Descreve uma intenção, não uma diferença, que é a única coisa que este campo pergunta.
Este rascunho é um cenário posterior: um segundo teste com a sua própria versão, a 1.4.3. Se ele servir para você, o resto das suas respostas descreve esse teste atual, e não o registro anterior das versões 1.4.1 e 1.4.2.
Como a PrimeTestLab apoia o seu teste e o seu pedido
Tudo o que está acima parte do princípio de que você tem um registro para usar como base. Se o bloqueio é o próprio registro, ou seja, encontrar 12 pessoas que fiquem participando por 14 dias sem interrupção, essa é a parte que fazemos. Pessoas reais em dispositivos reais, com início em 4-6 horas, durante os 14 dias completos e com o progresso à vista enquanto acontece.
O nosso plano Starter oferece 12 testadores por US$ 19,99, o plano Professional oferece 20 testadores por US$ 29,99 e o plano Enterprise oferece 25 testadores por US$ 27,99, todos com a garantia dos 14 dias completos.
Exatamente o mínimo exigido
Mais cobertura nos mesmos 14 dias
Mais engajamento nos mesmos 14 dias
O que você leva para o formulário
Testadores identificados com histórico de participação sem interrupções, um registro do que eles fizeram e o feedback deles por escrito: a matéria-prima para a Q1, a Q3, a Q4 e a Q8. Quem escreve as respostas continua sendo você, porque elas precisam ser suas.
O que isso não faz por você
Não enviamos o formulário no seu lugar, não temos como influenciar uma análise e nada nesta página prevê uma decisão. Se algum serviço disser o contrário, é essa a promessa que você deve checar primeiro.
Compare os planos de teste fechado
Perguntas frequentes
Posso usar estes exemplos como modelo?
Como estrutura, sim. Como texto para enviar, não. Todos os fatos deles pertencem a um app fictício, então uma resposta que mantém esses fatos descreve o teste de outra pessoa. Troque cada nome, número, recurso e constatação; é exatamente por isso que o botão de copiar entrega um modelo com colchetes.
O que é o formulário de acesso de produção?
É o formulário que você preenche ao solicitar o acesso de produção depois de um teste fechado, e ele cobre o teste que você fez, o seu app ou jogo e a sua prontidão para a produção. Você chega a ele por “Solicitar o acesso de produção”, no painel do seu app no Play Console, e pode lê-lo antes pelo link Visualizar perguntas.
Qual é o tamanho máximo de cada resposta?
Todo exemplo aqui tem menos de 300 caracteres, e alguns desenvolvedores relatam um limite perto disso. Não foi possível verificar nenhum limite universal em vigor, então quem manda é o contador do seu formulário. Não há evidência publicada ligando o tamanho da resposta às suas chances.
Devo dizer que usei um serviço pago de testes?
Você pode responder com a verdade. Nenhuma orientação publicada sugere que citar um serviço contratado afete o resultado, e uma lista inventada de canais é o risco maior. Diga a origem e depois diga quem definiu os cenários, leu o feedback, fez as mudanças e as verificou.
E se eu não tiver analytics do teste?
Se você não coletou analytics de sessão, relate o que você sabe e deixe claro como você sabe. “Dez dos doze testadores me disseram que concluíram o cadastro” serve; uma duração média de sessão inventada não serve. Uma contagem vinda do relato dos testadores continua sendo uma contagem, desde que você diga isso.
E se eu não fiz nenhuma mudança durante o teste fechado?
A orientação não prescreve um número de atualizações, e um app que não mudou não é automaticamente um pedido fraco. O que enfraquece uma resposta é um teste sem explicação. Diga quais fluxos e condições foram verificados, quais foram os resultados e de onde eles vieram, e o que ficou sem solução.
Quanto tempo leva a análise do acesso de produção?
O Google afirma que costuma levar 7 dias ou menos e que pode demorar mais. Uma análise ainda em andamento não é uma recusa. Acompanhe o Play Console e o e-mail da conta, e responda a qualquer coisa que o Google pedir.
O Google pediu que eu continuasse testando. Quando posso solicitar de novo?
Leia a mensagem que você recebeu: algumas indicam um prazo adicional específico e outras não indicam nenhum, e o Google não publica um intervalo universal para uma nova solicitação. Em todos os casos, os 14 dias consecutivos mais recentes precisam ter pelo menos 12 testadores qualificados. Veja os passos de recuperação acima e o guia completo sobre mais testes necessários.
Conclusão
Resumo
Escreva cada resposta a partir do seu próprio registro: quem testou, o que essas pessoas fizeram, o que elas relataram, o que você lançou e como você verificou. Troque todo detalhe inventado desta página, escolha nas listas suspensas as opções que correspondem à sua situação, siga o texto e o contador que o seu formulário mostra e leia as respostas em conjunto, para ver se elas combinam.
Se o que falta é o registro, compare os planos de teste fechado.