Neste guia
Qualquer app pode ter bugs, não importa como foi feito. Esta página trata dos tipos de falha que vale procurar quando você não escreveu cada linha, e de como um testador pode descrevê-las para que você as corrija rapidamente. Ela não afirma com que frequência nada falha.
Padrões de falha para testar
- Funciona só no caminho feliz. Tudo funciona se você fizer o que o prompt descreveu. Tente pular uma etapa, voltar ou repetir uma.
- Estados vazios e de erro. O que uma lista mostra sem dados? O que acontece quando uma requisição falha? Uma tela em branco é um bug, mesmo que nada tenha travado.
- Estado perdido ao girar ou voltar. Gire o celular, troque de app, volte. O texto digitado ainda está lá?
- Telas que parecem certas em um só celular. Telas pequenas, fontes grandes e entalhes podem esconder botões ou cortar textos.
- Permissões. Negue uma permissão e veja se o app explica o motivo ou simplesmente para.
- Offline e rede lenta. Spinners que nunca terminam, falhas silenciosas, entradas perdidas.
- Botões que não fazem nada. Um controle que parece pronto, mas não está conectado a nada.
- Login e sessões. Sair da conta, entrar em um segundo aparelho, uma sessão expirada.
- Conteúdo de demonstração esquecido. Dados de exemplo, contas de teste, textos de exemplo.
O que um relatório útil contém
Um testador que escreve "travou" não dá nada para você agir. Peça:
- Aparelho e versão do sistema.
- Versão / build do app.
- Passos, numerados, a partir de um início limpo.
- Resultado esperado.
- Resultado real, com uma captura de tela ou gravação de tela.
- Com que frequência acontece (sempre, às vezes, uma vez).
Mais em modelo de relatório de bug para testadores de apps e como dar feedback útil sobre um app.
Transforme um relatório em prompt
Cole o relatório como está e acrescente o contexto que seu assistente não tem:
Aqui está um relatório de bug de um testador.
[cole o relatório]
Tela ou arquivo relevante: [nome]
Explique primeiro a causa provável e depois proponha a menor mudança que corrige o problema.
Não altere comportamentos não relacionados.
Depois, repita você mesmo os passos exatos do testador. Uma correção só é correção quando os passos deixam de reproduzir o problema e quando os passos que funcionavam antes continuam funcionando.
Mantenha uma lista
Uma linha por bug: relatório, status (aberto, corrigido, testar de novo) e número do build. Peça ao testador que teste a correção novamente.
Próximo passo
O AppReviewX oferece feedback privado e estruturado, pensando nos campos acima. Cada feedback que você escrever rende 1 crédito; contas novas começam com 0. Comece grátis.
Relacionados: hub de vibe coding, teste fechado para um app feito com IA, destacar-se entre muitos apps novos.