Testadores perdem a primeira sessão quando o backend está fora do ar, a conta de teste não funciona ou o app aponta para o servidor errado. Execute esta lista antes de enviar qualquer convite. Cada item tem um motivo e uma forma de verificar.
| # | Item | Por quê | Como verificar |
|---|---|---|---|
| 1 | A build aponta para o backend de teste, não para produção | Ações de teste não podem afetar usuários reais nem dinheiro real | Confira a URL base na build instalada; faça uma ação e procure-a no banco de teste |
| 2 | O backend de teste está no ar e acessível de fora da sua rede | Os testadores não estão no seu Wi-Fi ou na sua VPN | Acesse por dados móveis em um celular |
| 3 | Contas de teste existem para cada papel (usuário novo, regular, admin se houver) | Testadores não devem perder tempo se cadastrando ou adivinhando | Entre com cada uma a partir de uma instalação limpa |
| 4 | As credenciais estão no convite, não só na sua cabeça | Evita a primeira pergunta de suporte | Releia o convite como se fosse um estranho |
| 5 | Os dados de exemplo são realistas (nomes longos, listas vazias e cheias, caracteres especiais) | Dados vazios ou arrumados escondem bugs de layout e de lógica | Percorra as principais listas com esses dados |
| 6 | Os dados podem ser redefinidos rapidamente | Depois de uma rodada ruim de testes, você precisa de um estado limpo | Execute seu reset uma vez e cronometre |
| 7 | Pagamentos e e-mails rodam em modo sandbox/teste | Sem cobranças reais nem e-mails para endereços reais | Faça uma compra de teste; confira para onde vão os e-mails |
| 8 | As feature flags estão definidas para a build testada | Funcionalidades inacabadas devem ficar ocultas ou marcadas | Liste as flags e seus valores para essa build |
| 9 | As chaves de terceiros (mapas, push, autenticação) são válidas para a build de teste | Chaves ligadas a outro ID de app falham em silêncio | Dispare cada serviço uma vez em um dispositivo |
| 10 | As notificações push chegam a um dispositivo de teste | Costumam estar mal configuradas só nas builds de teste | Envie uma a partir do backend |
| 11 | O relatório de falhas e erros está ativo, com o número da build anexado | Sem isso, você não recebe logs dos testadores | Force um travamento de teste e encontre-o no painel |
| 12 | O log não guarda senhas nem dados pessoais | Dados de teste ainda podem ser de pessoas reais | Leia uma amostra das linhas de log |
| 13 | Os testadores conseguem instalar a build (link, grupo ou convite funciona) | A falha inicial mais comum | Instale pelo caminho exato que os testadores vão usar, em um segundo dispositivo |
| 14 | O número da build está visível no app | Todo relato precisa de uma versão | Abra as configurações ou uma tela "sobre" |
| 15 | Existe uma lista de problemas conhecidos | Poupa os testadores de reportar o que você já sabe | Escreva antes do convite |
| 16 | Há um único lugar para enviar feedback e você vai vê-lo | Feedback espalhado se perde | Envie um relatório de teste para você mesmo |
Modelo: nota de prontidão pré-convite
Ambiente: [URL de homologação] Build: [número] Data: [data]
Verificado por: [nome]
[ ] 1-16 acima concluídos. Exceções: [lista]
Problemas conhecidos: [lista]
Procedimento de reset: [passos]
Adaptar
Remova os itens que não se aplicam (sem backend, sem pagamentos). Acrescente o que for específico da sua stack, como uma migração de banco ou um modo de demonstração com dados. Para testar migrações, veja as verificações relacionadas em testar migrações de banco sem perder dados.
Relacionados
- Hub: hub de checklists de teste de apps mobile
- Checklist de política de privacidade para apps mobile
- Checklist pré-lançamento do app: 30 coisas para verificar
Quando o ambiente estiver pronto, o AppReviewX pode fornecer feedback privado e estruturado de testadores. Um feedback = 1 crédito; contas novas começam com 0. Comece grátis.