Um relatório de bug é uma ferramenta de comunicação e também um registro de defeito. Um bom relatório economiza tempo: os desenvolvedores podem reproduzir o problema, os gerentes entendem seu impacto e o QA pode rastrear a correção e os riscos relacionados.
O que um relatório geralmente contém
- →Um título claro identificando o problema.
- →Ambiente e pré-condições relevantes.
- →Etapas de reprodução.
- →Resultados reais e esperados.
- →Evidências: capturas de tela, vídeo, logs, traces de rede, payloads ou stack traces.
O que torna um relatório forte
- →O problema é fácil de entender e reproduzir.
- →Os fatos são diferenciados das interpretações.
- →O impacto no usuário, nos negócios ou no sistema é explicado.
- →Detalhes irrelevantes não obscurecem as decisões.
Erros comuns
- →Um título vago como “botão não funciona”.
- →Resultados esperados ausentes ou excessivamente abstratos.
- →Etapas que omitem condições essenciais e não conseguem reproduzir o defeito.
- →Prioridade e severidade baseadas na emoção e não no risco.
Orientação prática
Escreva para alguém que não conheça seu contexto de teste. Quanto mais rápido essa pessoa conseguir estabelecer o que falhou, como reproduzir e por que importa, melhor será o relatório.
Exemplo resolvido: um relatório de defeito reproduzível
O exemplo a seguir é um treinamento fictício, não um defeito observado em um produto real. Suponha que o requisito REG-04 diga que um apelido aceita de 3 a 12 letras ASCII, inclusive. O build do exemplo rejeita incorretamente exatamente 3 letras. Mantenha relatos reais vinculados a um requisito aprovado e a uma observação real.
ID: DEMO-17
Título: O cadastro rejeita um apelido de 3 letras permitido por REG-04
Ambiente: build fictício de treinamento 1.0; navegador e sistema: registrar versões reais
Pré-condições: formulário de cadastro aberto; todos os outros campos contêm dados válidos
Passos:
1. Insira abc no campo Apelido.
2. Mova o foco para o próximo campo.
3. Envie o formulário.
Esperado: nenhum erro de tamanho do apelido; o cadastro pode continuar.
Resultado real neste cenário fictício: "Minimum 4 characters"; o envio é bloqueado.
Reprodutibilidade: 3 de 3 tentativas após reiniciar o formulário.
Impacto: não é possível cadastrar um apelido permitido.
Evidências a coletar: captura de tela, ID do build, horário e requisição/resposta sanitizada.
Requisito: REG-04.
Severidade / prioridade: definir conforme os critérios da equipe e o contexto do lançamento.O título identifica a ação, a entrada e o desvio. Ele não presume que o backend seja responsável. Se apenas a interface foi observada, registre esse fato; inspecione a requisição antes de afirmar uma causa no servidor. As capturas de tela e os logs listados acima são evidências a coletar, não anexos fornecidos por este guia.
Modelo de relatório copiável
Título:
Build / ambiente:
Requisito ou fonte do comportamento esperado:
Pré-condições e dados de teste:
Passos:
Resultado esperado:
Resultado real:
Reprodutibilidade:
Impacto no usuário:
Evidências sanitizadas:
Issue / caso de teste relacionado:Antes de enviar, peça a um colega que siga apenas os passos registrados. Remova credenciais e dados pessoais das evidências. Um relatório que ainda não pode ser reproduzido ainda pode ser útil: indicar o que se sabe, com que frequência aconteceu e quais informações estão faltando.