Modelo de Relatório de Bug Word: Pronto para Preencher

Um relatório de bug é o documento usado para registrar uma falha, um comportamento inesperado ou uma inconsistência encontrada em um sistema, aplicativo, site, equipamento ou processo digital. Seu objetivo é transformar uma ocorrência percebida por uma pessoa em informações claras e verificáveis para que a equipe técnica consiga analisar, reproduzir, priorizar e corrigir o problema.

Este modelo de relatório de bug Word foi estruturado para ser copiado e editado no Microsoft Word ou em outro editor de texto compatível. Ele organiza os dados que realmente ajudam no diagnóstico: identificação do erro, ambiente em que ocorreu, passos para reprodução, resultado esperado, resultado obtido, evidências, impacto e nível de prioridade. Ao preencher cada campo com objetividade, a comunicação entre usuários, atendimento, qualidade, produto e desenvolvimento se torna mais eficiente.

Embora seja muito utilizado por profissionais de QA, suporte e desenvolvimento de software, o relatório também pode ser preenchido por qualquer colaborador que encontre uma falha. O ponto central é relatar fatos observáveis, evitando conclusões precipitadas sobre a causa do problema. Por exemplo, em vez de escrever “o sistema está com defeito”, informe qual tela foi acessada, quais ações foram realizadas, qual mensagem apareceu e em que momento a falha ocorreu.

Quando usar o relatório de bug

Use este documento sempre que uma funcionalidade não se comportar conforme o esperado, apresente erro técnico, gere informação incorreta, impeça uma tarefa ou cause risco ao usuário, ao negócio ou à segurança. Ele pode ser utilizado em testes internos antes de uma versão ser publicada, durante a operação normal de um sistema ou após uma reclamação recebida pelo suporte.

• Ao identificar travamentos, lentidão anormal, telas em branco ou mensagens de erro.
• Quando os cálculos, cadastros, relatórios ou permissões do sistema apresentarem resultado incorreto.
• Quando uma funcionalidade descrita em requisito, manual ou história de usuário não for atendida.
• Para documentar falhas encontradas em aplicativos móveis, sites, sistemas corporativos, APIs, integrações e equipamentos.
• Quando for necessário encaminhar evidências para a equipe responsável pela correção.
• Para acompanhar a priorização, o status e a validação da solução aplicada.

Nem toda sugestão de melhoria é um bug. Se a funcionalidade opera como foi definida, mas poderia ser mais simples, rápida ou intuitiva, o registro adequado normalmente é uma solicitação de melhoria. Já o bug existe quando há divergência entre o comportamento esperado e o comportamento efetivamente observado.

Modelo completo de relatório de bug

Copie o texto abaixo para o Word e substitua todos os campos entre colchetes pelas informações do caso. Se algum item não se aplicar, registre “Não se aplica” e, se não houver dado disponível, informe “Não identificado” em vez de deixar uma lacuna que possa gerar dúvidas.

RELATÓRIO DE BUG

1. Identificação do registro
Identificador do bug: [BUG-0001 OU CÓDIGO INTERNO]
Data e horário do registro: [DD/MM/AAAA – HH:MM]
Registrado por: [NOME COMPLETO]
Área ou equipe: [SETOR / EQUIPE]
Canal de identificação: [TESTE / USUÁRIO / SUPORTE / MONITORAMENTO / OUTRO]

2. Resumo do problema
Título do bug: [DESCRIÇÃO CURTA E OBJETIVA DA FALHA]
Produto, sistema ou aplicação: [NOME DO SISTEMA]
Módulo ou funcionalidade afetada: [NOME DO MÓDULO / TELA / RECURSO]
Versão ou release: [VERSÃO DO SISTEMA, BUILD OU RELEASE]
Data e horário em que ocorreu: [DD/MM/AAAA – HH:MM, SE CONHECIDO]

3. Classificação
Tipo de falha: [FUNCIONAL / VISUAL / DESEMPENHO / SEGURANÇA / INTEGRAÇÃO / DADOS / OUTRO]
Severidade: [BLOQUEADORA / CRÍTICA / ALTA / MÉDIA / BAIXA]
Prioridade: [URGENTE / ALTA / MÉDIA / BAIXA]
Status inicial: [ABERTO / EM ANÁLISE / REPRODUZIDO / OUTRO]

4. Ambiente de ocorrência
Dispositivo: [COMPUTADOR / CELULAR / TABLET / OUTRO]
Sistema operacional e versão: [EX.: WINDOWS 11 / ANDROID 14 / IOS 17]
Navegador e versão, se aplicável: [EX.: GOOGLE CHROME 123]
Rede ou ambiente: [PRODUÇÃO / HOMOLOGAÇÃO / DESENVOLVIMENTO / WIFI / VPN]
Usuário ou perfil utilizado: [PERFIL, SEM EXPOR SENHAS OU DADOS SIGILOSOS]
Outras condições relevantes: [CONFIGURAÇÕES, PERMISSÕES OU DADOS DE TESTE]

5. Pré-condições
[INFORME O QUE PRECISA ESTAR CONFIGURADO ANTES DE EXECUTAR O TESTE. EX.: USUÁRIO ATIVO, PEDIDO CADASTRADO, PERMISSÃO DE GESTOR LIBERADA.]

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

7. Resultado esperado
[DESCREVA O QUE O SISTEMA DEVERIA FAZER DE ACORDO COM A REGRA, REQUISITO, TELA OU PROCESSO.]

8. Resultado obtido
[DESCREVA EXATAMENTE O QUE ACONTECEU, INCLUINDO MENSAGENS, VALORES, COMPORTAMENTOS E MOMENTO DA FALHA.]

9. Impacto identificado
Quantidade estimada de usuários afetados: [NÚMERO OU ESTIMATIVA]
Impacto operacional ou financeiro: [DESCREVER]
Existe alternativa temporária? [SIM / NÃO]
Descrição da alternativa, se houver: [DESCREVER]
Risco envolvendo dados pessoais, sigilo ou segurança: [SIM / NÃO / NÃO IDENTIFICADO]
Detalhamento do risco: [DESCREVER, SEM INSERIR DADOS PESSOAIS DESNECESSÁRIOS]

10. Evidências anexadas ou referenciadas
[PRINTS DE TELA, VÍDEO, LOGS, URL, NÚMERO DO CHAMADO, ARQUIVO DE TESTE OU OUTRAS EVIDÊNCIAS.]

11. Observações e encaminhamento
Responsável pela análise: [NOME / EQUIPE]
Prazo ou ação sugerida: [DESCREVER]
Observações adicionais: [DESCREVER]

12. Validação da correção
Data da retestagem: [DD/MM/AAAA]
Responsável pela validação: [NOME COMPLETO]
Resultado da validação: [CORRIGIDO / NÃO CORRIGIDO / PARCIALMENTE CORRIGIDO]
Comentários da validação: [DESCREVER]
Status final: [ENCERRADO / REABERTO / PENDENTE]

Como preencher o relatório passo a passo

1. Crie um título que facilite a triagem. O título deve indicar a ação, o local e a falha. Um bom exemplo é: “Ao finalizar pedido, sistema exibe erro e não gera comprovante”. Evite títulos vagos como “erro no sistema” ou “não funciona”.
2. Registre o ambiente com precisão. Muitas falhas acontecem apenas em determinado navegador, dispositivo, versão ou perfil de acesso. Informe esses detalhes para reduzir o tempo de investigação. Se o erro ocorreu em produção, homologação ou desenvolvimento, deixe isso explícito.
3. Descreva as pré-condições. Elas mostram o cenário necessário para reproduzir o problema. Pode ser a existência de um cadastro, uma permissão específica, uma integração ativa ou o uso de determinado tipo de dado.
4. Liste passos simples e numerados. Cada passo deve representar uma ação. Outra pessoa deve conseguir repeti-los sem precisar perguntar o que você quis dizer. Sempre que possível, use dados de teste e identifique-os sem expor informações confidenciais.
5. Separe resultado esperado e resultado obtido. Essa comparação é a parte mais importante do relatório. O esperado deve se basear em uma regra conhecida, como requisito aprovado, fluxo de negócio, manual ou versão anterior validada. O obtido deve relatar somente o que ocorreu.
6. Classifique severidade e prioridade com critério. Severidade representa o tamanho do dano técnico ou funcional; prioridade indica a urgência de atendimento para o negócio. Uma falha visual pode ter baixa severidade, mas ser prioridade alta se afetar uma campanha que será lançada no mesmo dia.
7. Anexe evidências úteis. Capturas de tela, vídeos curtos, logs e mensagens de erro tornam o relato mais confiável. Antes de anexar qualquer material, revise se há CPF, e-mail, telefone, senhas, tokens, dados médicos ou outras informações pessoais. A coleta e o compartilhamento de dados devem observar a finalidade e as medidas de segurança previstas na Lei Geral de Proteção de Dados, Lei nº 13.709/2018.
8. Registre a validação após a correção. Um bug não deve ser encerrado apenas porque foi informado como corrigido. Repita os passos no ambiente definido, confira se o resultado esperado foi alcançado e verifique se não surgiram efeitos colaterais relevantes.

Perguntas comuns sobre relatório de bug

Qual é a diferença entre severidade e prioridade?

A severidade mede o impacto da falha sobre o funcionamento técnico ou funcional. Um erro que impede o acesso ao sistema tende a ser bloqueador ou crítico. A prioridade define quando ele deve ser resolvido, considerando usuários afetados, prazos, obrigações do negócio e existência de alternativa temporária. A classificação pode variar de acordo com a política interna da organização.

Quem pode abrir um relatório de bug?

Qualquer pessoa que identifique uma falha pode iniciar o registro: usuário final, atendente, analista de suporte, profissional de qualidade, gestor ou desenvolvedor. Contudo, a empresa pode estabelecer responsáveis pela triagem, pela confirmação da reprodução e pela classificação final do chamado.

É obrigatório anexar print ou vídeo?

Não é obrigatório em todos os casos, mas é fortemente recomendado quando a evidência puder esclarecer a ocorrência. Em falhas intermitentes, logs, data, horário, identificador da transação e informações do ambiente podem ser ainda mais importantes do que uma captura de tela. Nunca inclua senhas, chaves de acesso ou dados pessoais sem necessidade.

Como definir se um bug é bloqueador?

Em geral, considera-se bloqueador o problema que impede a continuidade de uma operação essencial e não possui alternativa viável, como impossibilidade de login para todos os usuários, indisponibilidade total de um serviço ou perda de dados em processo crítico. A decisão deve seguir os critérios acordados entre as áreas de produto, tecnologia e negócio.

Posso usar este modelo para bugs em equipamentos?

Sim. Para equipamentos, máquinas ou dispositivos conectados, adapte os campos de ambiente e inclua modelo do equipamento, número de série quando permitido, versão do firmware, condições de uso, data de manutenção e sinais observados. O princípio continua o mesmo: documentar o cenário, o comportamento esperado, o comportamento obtido e as evidências.

Este modelo de relatório de bug tem caráter informativo e deve ser adaptado aos procedimentos, políticas de segurança, níveis de serviço e ferramentas adotados pela sua organização. Para casos que envolvam incidente de segurança, vazamento de dados ou obrigação regulatória, procure a orientação das áreas técnicas, jurídicas e de privacidade responsáveis.