Modelo de Relatório de Bug: Guia Completo para Registrar Falhas

Um relatório de bug é o documento usado para registrar uma falha identificada em um sistema, aplicativo, site, software ou funcionalidade digital. Ele transforma uma percepção genérica — como “a tela não funciona” — em uma descrição objetiva e reproduzível do problema. Quando bem preenchido, permite que equipes de desenvolvimento, testes, suporte e produto compreendam a ocorrência, avaliem sua prioridade e trabalhem na correção com mais rapidez.

O modelo de relatório de bug deve reunir dados essenciais, como o ambiente em que a falha ocorreu, o passo a passo para reproduzi-la, o resultado esperado, o resultado efetivamente encontrado, evidências e o nível de impacto. Essas informações evitam retrabalho, reduzem trocas de mensagens e ajudam a diferenciar um defeito técnico de uma dúvida de uso, uma limitação já prevista ou uma solicitação de melhoria.

Embora seja muito usado por profissionais de qualidade de software (QA), programadores e analistas de suporte, esse documento também é útil para usuários-chave, gestores, clientes em projetos de homologação e qualquer pessoa responsável por comunicar erros em ferramentas digitais. O ideal é elaborar um relatório para cada problema identificado, com linguagem clara, fatos verificáveis e sem atribuir culpa a pessoas ou setores.

Quando usar um relatório de bug

Use o relatório de bug sempre que uma funcionalidade apresentar um comportamento diferente do que foi definido, documentado ou esperado pelo usuário. O registro formal é especialmente importante quando a falha precisa ser encaminhada a outra equipe, acompanhada em uma ferramenta de chamados ou priorizada em uma reunião de produto.

• Ao identificar erro em páginas, formulários, botões, links, cálculos ou integrações.
• Quando o sistema trava, fecha inesperadamente, apresenta lentidão anormal ou exibe mensagens de erro.
• Ao encontrar divergência entre a regra de negócio definida e o resultado entregue pela aplicação.
• Durante testes de desenvolvimento, homologação, aceitação, atualização ou lançamento de uma nova versão.
• Quando houver falha de compatibilidade com navegador, sistema operacional, dispositivo ou tamanho de tela específico.
• Para registrar incidentes que afetem segurança, acesso, disponibilidade, pagamentos ou dados dos usuários.
• Ao encaminhar uma ocorrência ao fornecedor de um software ou à equipe interna de tecnologia.

Nem toda observação deve ser classificada automaticamente como bug. Se a funcionalidade opera conforme a especificação, mas poderia ser mais prática ou visualmente diferente, o registro pode ser uma sugestão de melhoria. Da mesma forma, se faltam permissões de acesso ao usuário, pode tratar-se de uma solicitação de perfil. Antes de abrir o relato, consulte instruções, requisitos e ocorrências já cadastradas para evitar duplicidade.

Modelo completo de relatório de bug

Copie o modelo abaixo e substitua todos os campos entre colchetes pelas informações da ocorrência. Caso um item não se aplique, informe “Não se aplica” em vez de deixá-lo em branco.

RELATÓRIO DE BUG

1. Identificação do registro
Número do chamado/ID: [NÚMERO OU CÓDIGO DO BUG]
Data e hora do registro: [DD/MM/AAAA – HH:MM]
Registrado por: [NOME COMPLETO]
Área/equipe: [NOME DA ÁREA OU EMPRESA]
Canal de identificação: [TESTE / HOMOLOGAÇÃO / PRODUÇÃO / SUPORTE / OUTRO]

2. Resumo do problema
Título do bug: [DESCRIÇÃO CURTA E OBJETIVA DA FALHA]
Módulo ou funcionalidade afetada: [NOME DO MÓDULO, PÁGINA OU RECURSO]
URL, tela ou caminho de acesso: [LINK OU CAMINHO NO SISTEMA]

3. Classificação
Tipo de ocorrência: [FUNCIONAL / VISUAL / DESEMPENHO / SEGURANÇA / INTEGRAÇÃO / DADOS / OUTRO]
Severidade: [BLOQUEADORA / CRÍTICA / ALTA / MÉDIA / BAIXA]
Prioridade sugerida: [URGENTE / ALTA / MÉDIA / BAIXA]
Frequência: [SEMPRE / INTERMITENTE / OCORREU UMA VEZ]
Status inicial: [ABERTO]

4. Ambiente em que ocorreu
Sistema/aplicação: [NOME DO SISTEMA]
Versão ou compilação: [NÚMERO DA VERSÃO/BUILD]
Ambiente: [DESENVOLVIMENTO / HOMOLOGAÇÃO / PRODUÇÃO]
Dispositivo: [COMPUTADOR / CELULAR / TABLET – MODELO, SE NECESSÁRIO]
Sistema operacional e versão: [EX.: WINDOWS 11 / ANDROID 14]
Navegador e versão: [EX.: GOOGLE CHROME 122 – SE APLICÁVEL]
Usuário ou perfil utilizado: [PERFIL DE ACESSO, SEM EXPOR SENHAS]

5. Pré-condições
[INFORME O QUE DEVE ESTAR CONFIGURADO ANTES DO TESTE, COMO USUÁRIO CADASTRADO, PEDIDO CRIADO, PERMISSÃO ATIVA OU DADOS ESPECÍFICOS.]

6. Passos para reproduzir
1. [PRIMEIRA AÇÃO REALIZADA.]
2. [SEGUNDA AÇÃO REALIZADA.]
3. [TERCEIRA AÇÃO REALIZADA.]
4. [AÇÃO FINAL QUE PROVOCA A FALHA.]

7. Resultado esperado
[DESCREVA O COMPORTAMENTO CORRETO QUE O SISTEMA DEVERIA APRESENTAR.]

8. Resultado obtido
[DESCREVA EXATAMENTE O QUE ACONTECEU, INCLUINDO MENSAGENS DE ERRO, VALORES INCORRETOS, TRAVAMENTOS OU COMPORTAMENTOS INESPERADOS.]

9. Impacto identificado
[INFORME AS CONSEQUÊNCIAS: USUÁRIO NÃO CONSEGUE CONCLUIR UMA TAREFA, DADOS FICAM INCORRETOS, OPERAÇÃO É INTERROMPIDA, HÁ RISCO DE EXPOSIÇÃO DE DADOS ETC.]

10. Evidências
Capturas de tela: [NOME DO ARQUIVO OU LINK]
Vídeo de reprodução: [NOME DO ARQUIVO OU LINK]
Logs, código de erro ou console: [INFORMAR DADOS RELEVANTES]
Outras informações: [DETALHES ADICIONAIS]

11. Acompanhamento e validação
Responsável pela análise: [NOME OU EQUIPE]
Responsável pela correção: [NOME OU EQUIPE]
Data prevista para correção: [DD/MM/AAAA]
Versão da correção: [VERSÃO/BUILD]
Resultado do reteste: [APROVADO / REPROVADO / PENDENTE]
Validado por: [NOME COMPLETO]
Data de validação: [DD/MM/AAAA]
Status final: [RESOLVIDO / REABERTO / CANCELADO / DUPLICADO]

Observações
[REGISTRE INFORMAÇÕES COMPLEMENTARES, DECISÕES, CONTORNOS TEMPORÁRIOS OU REFERÊNCIAS A CHAMADOS RELACIONADOS.]

Como preencher o relatório passo a passo

1. Crie um título específico. Resuma a falha indicando a ação e o resultado. Em vez de “erro no cadastro”, prefira “Sistema não salva cadastro de cliente ao informar CEP internacional”. Um título objetivo facilita pesquisas e triagens.
2. Informe onde o problema ocorreu. Identifique sistema, versão, ambiente, dispositivo, sistema operacional e navegador. Uma falha pode ocorrer apenas na produção, em um navegador determinado ou depois de certa atualização.
3. Defina a severidade com critério. Um erro bloqueador impede totalmente uma operação essencial, como acesso ao sistema ou conclusão de pagamento. Uma falha baixa pode ser um desalinhamento visual sem prejuízo funcional. A prioridade considera também urgência, quantidade de pessoas afetadas e impacto para o negócio.
4. Liste passos reproduzíveis. Escreva as ações na ordem exata em que foram feitas. Evite instruções vagas como “fiz o processo normal”. Quem receber o chamado deve conseguir repetir o cenário sem depender de explicações adicionais.
5. Separe resultado esperado de resultado obtido. No primeiro campo, registre o comportamento previsto pela regra de negócio ou requisito. No segundo, descreva o fato observado. Essa comparação é o núcleo do relatório e demonstra claramente a divergência.
6. Anexe evidências úteis. Capturas de tela, vídeo, horários, identificadores de transação e trechos de log podem acelerar a análise. Antes de anexar materiais, oculte senhas, tokens, documentos pessoais, dados bancários e outras informações confidenciais.
7. Registre o reteste. Depois da correção, repita os passos no ambiente e na versão informados. Caso o resultado esteja adequado, registre a aprovação e a versão validada. Se a falha persistir ou gerar efeito colateral, reabra o chamado com as novas evidências.

Boas práticas para um registro eficiente

Prefira dados observáveis a conclusões técnicas sem comprovação. Dizer que “o botão Salvar permaneceu carregando por mais de dois minutos após o envio do formulário” é mais útil do que afirmar que “o servidor está com defeito”. A equipe responsável poderá investigar a causa; o papel do relatório é descrever o cenário, o impacto e as provas disponíveis.

Também é recomendável padronizar a classificação de severidade na organização. A tabela a seguir apresenta uma referência simples:

Se o relato envolver informações pessoais, observe a Lei Geral de Proteção de Dados Pessoais — LGPD (Lei nº 13.709/2018). O relatório deve conter apenas o mínimo necessário para a investigação. Sempre que possível, use dados fictícios em ambientes de teste, mascare informações identificáveis e restrinja o acesso aos anexos conforme as regras internas de segurança.

Perguntas comuns

Qual é a diferença entre bug, incidente e melhoria?

Bug é uma falha ou comportamento divergente do que deveria ocorrer. Incidente é uma interrupção ou degradação de serviço percebida na operação, que pode ou não ser causada por um bug. Já a melhoria é uma proposta de alteração ou evolução em algo que funciona conforme o previsto.

Quem pode abrir um relatório de bug?

Qualquer pessoa que identifique a falha pode realizar o registro, desde que forneça informações suficientes para análise. Em muitas organizações, usuários comunicam o suporte, que valida os dados e formaliza o chamado para a equipe técnica.

É necessário anexar print ou vídeo?

Não é obrigatório em todos os casos, mas é altamente recomendável quando a evidência puder esclarecer o problema. Para erros de integração ou desempenho, logs, horário exato da ocorrência e identificadores de requisição podem ser ainda mais relevantes do que imagens.

O que fazer se o problema não puder ser reproduzido?

Registre que a ocorrência é intermitente, informe data, horário, usuário afetado, ambiente e qualquer condição observada antes da falha. Não descarte o chamado somente porque ele não aconteceu novamente no primeiro teste; encaminhe-o para análise com as evidências disponíveis.

Este modelo de relatório de bug tem caráter informativo e deve ser adaptado aos procedimentos, ferramentas, políticas de segurança e critérios de qualidade adotados por cada organização.