Uma lista de problemas conhecidos mostra aos testadores o que você já sabe, para que eles gastem o tempo com o que você ainda não sabe. Ela reduz reports duplicados e deixa claro quais problemas são aceitos nesta build e quais não são.
Template (copie e cole)
PROBLEMAS CONHECIDOS: [Nome do app], build [versão / número da build], [data]
Já conhecidos, não precisa reportar:
1. [Título curto] - [Onde acontece]. Contorno: [contorno ou "nenhum"]. Status: [será corrigido na build X / aceito por enquanto].
2. ...
Ainda não prontos, por favor ignorem:
- [Tela ou recurso] - [motivo em uma linha]
Continuem reportando:
- Qualquer coisa que trave ou perca dados, mesmo em uma área listada acima.
- Um problema conhecido que se comporte de forma diferente do descrito aqui.
Como reportar: [link ou canal]. Inclua aparelho, versão do SO e passos.
Exemplo (inventado)
PROBLEMAS CONHECIDOS: Pocket Budget, build 0.9.3 (42), 2026-10-17
Já conhecidos, não precisa reportar:
1. Modo escuro: os rótulos do gráfico são difíceis de ler na tela Estatísticas. Contorno: use o modo claro. Status: será corrigido na próxima build.
2. A exportação CSV é lenta com mais de algumas centenas de registros. Contorno: nenhum. Status: aceito por enquanto.
Ainda não prontos, por favor ignorem:
- Ajustes > Backup - ainda não está conectado
Continuem reportando:
- Qualquer coisa que trave ou perca dados, mesmo em uma área listada acima.
- Um problema conhecido que se comporte de forma diferente do descrito aqui.
Como reportar: responda a esta mensagem. Inclua aparelho, versão do SO e passos.
Como adaptar
- Seja breve. Se a lista tiver mais de uns dez itens, os testadores param de ler. Remova os itens corrigidos a cada build.
- Nomeie a build. Uma lista sem número de build fica errada na versão seguinte.
- Descreva sintomas, não causas. Os testadores reconhecem o que veem, não os nomes internos dos seus tickets.
- Mantenha as linhas "continuem reportando". Senão, os testadores acham que uma área listada está fora dos limites, e você deixa passar novos crashes ali.
- Não esconda problemas graves. Um bug conhecido de perda de dados deve estar na lista, com um aviso, e não em silêncio.
- Use junto com a build. Envie a lista na mesma mensagem que entrega a build e vincule-a às suas notas de lançamento.
Relacionados: checklist de go / no-go de lançamento, checklist de hotfix, e o hub checklists de teste de apps mobile.
Quer testadores que reportem de forma estruturada? Comece grátis.