1. Troque “não funciona” por uma sequência reproduzível
A frase “a aplicação não funciona” descreve o impacto, mas não dá pistas suficientes para encontrar a causa. Um bom relatório começa com os passos exatos: abrir a aplicação, entrar numa secção, selecionar uma opção e indicar o momento em que o comportamento deixa de ser o esperado.
Se o problema só acontece depois de uma sequência específica, essa sequência é uma das informações mais valiosas. O objetivo do primeiro diagnóstico é conseguir reproduzir o erro de forma consistente.
2. Diga o que esperava e o que aconteceu
Dois utilizadores podem interpretar o mesmo comportamento de forma diferente. Por isso, escreva “resultado esperado” e “resultado observado”. Exemplo: esperado — a lista é atualizada depois de carregar no botão; observado — aparece um indicador de carregamento que nunca termina.
Esta comparação ajuda a distinguir um erro técnico de uma diferença de expectativa ou de uma funcionalidade que ainda não foi implementada.
3. Inclua o ambiente
Versão da aplicação, modelo do dispositivo, versão do Android, navegador e página afetada podem ser relevantes. Nem todos os erros dependem destes dados, mas uma incompatibilidade de versão pode tornar-se óbvia quando o problema ocorre apenas num grupo específico.
Quando o erro envolve rede, indique se acontece em Wi-Fi e dados móveis, se outros conteúdos carregam e se existe VPN ou filtragem ativa. Não é necessário enviar configurações privadas; basta descrever o contexto.
4. Capturas de ecrã ajudam, mas precisam de contexto
Uma captura mostra o estado visual, não mostra necessariamente os passos que levaram até ali. Combine-a com uma descrição curta. Se houver mensagem de erro, copie o texto quando possível, porque pesquisar uma mensagem exata é mais fiável do que interpretar uma imagem.
Antes de enviar uma captura, confirme que não contém palavras-passe, tokens, dados bancários, endereços privados ou informação pessoal de terceiros.
5. Indique frequência e impacto
“Acontece sempre”, “aconteceu uma vez” e “acontece aproximadamente uma vez em dez” são cenários diferentes. Indicar frequência ajuda a escolher a estratégia de teste. O impacto também importa: bloqueia completamente uma função principal ou existe uma alternativa temporária?
6. Um modelo simples de relatório
Um pedido de suporte pode ser organizado assim: projeto e versão; dispositivo/ambiente; passos para reproduzir; resultado esperado; resultado observado; frequência; mensagem de erro; evidência adicional. Esta estrutura costuma ser mais útil do que uma descrição longa sem ordem.
Quanto mais fácil for reproduzir o problema, mais rapidamente se consegue separar hipóteses e testar uma correção.