Bug é a palavra informal para defeito; defeito (defect) é o termo formal para qualquer falha em que o software não atende ao requisito. Issue é o termo guarda-chuva que cobre defeitos, pedidos de funcionalidade, tarefas e dúvidas. Na prática descrevem a mesma coisa em níveis diferentes de cerimônia — e o que gera confusão é misturar os três dentro do mesmo time. As diferenças importam menos na conversa e mais em três lugares: o que você mede, o que você promete em contrato e o que você pede a quem reporta. Esta página propõe uma separação defensável, para colocar num glossário e parar de discutir.
A resposta curta
| Termo | Escopo | Onde aparece |
|---|---|---|
| Bug | Palavra informal para defeito. Geralmente algo que funcionava antes ou que claramente deveria funcionar | Dailies, chat, "tem um bug no pagamento" |
| Defeito (defect) | Termo formal: qualquer desvio entre comportamento real e esperado, tenha funcionado antes ou não | Relatórios de QA, auditorias, contratos, métricas |
| Issue | Termo guarda-chuva: tudo que exige decisão — defeito, pedido, tarefa, dúvida | Trackers, IDs de ticket, notas de versão |
| Error | Uma ação humana que produz resultado incorreto | Análise de causa raiz, post-mortems |
| Fault | A instrução ou dado errado dentro do software que provoca a falha | Discussão de engenharia, normas |
| Failure | O evento observável: o sistema não faz o que deve | Revisões de incidente, monitoração |
A cadeia: error, fault, failure
O modelo clássico, ainda usado em normas e útil em post-mortem:Por que "issue" é a palavra melhor para o seu tracker
Um tracker guarda mais que defeitos. Chame o objeto de issue — mantendo "bug" como palavra do dia a dia — e você tem um só lugar para:- defeitos (o comportamento está errado),
- pedidos de funcionalidade (o comportamento falta de propósito),
- tarefas (trabalho sem comportamento associado),
- dúvidas (nenhuma mudança de código esperada).
Onde a distinção ganha dinheiro
1. Contratos e SLA. Um acordo que promete "defeitos críticos corrigidos em 24 horas" precisa de definição escrita de defeito e crítico. Sem ela, toda discussão é negociação. "Bug" em contrato costuma ser vago demais para exigir. 2. Métricas. Densidade de defeitos, taxa de escape e taxa de reabertura só significam algo se a população é estável. Se metade dos seus "bugs" são pedidos, nenhum número se sustenta. 3. Auditoria e conformidade. Produtos regulados geralmente exigem registro de defeito rastreável com severidade, verificação e evidência de encerramento. É um artefato formal: a palavra defeito sinaliza essa formalidade.Bug ou pedido de funcionalidade?
A fronteira que gera mais discussão:| É defeito se… | É pedido se… |
|---|---|
| O comportamento contradiz um requisito escrito ou o design documentado | Não existe requisito e esse comportamento nunca foi prometido |
| Os usuários não conseguem concluir uma tarefa que antes concluíam | Conseguem concluir, só não do jeito que preferem |
| O estado do sistema fica inconsistente ou há perda de dados | O sistema é consistente; a saída apenas não é a desejada |
| Afeta acessibilidade, segurança ou integridade dos dados | É preferência de layout, texto ou fluxo |
Bug ou "error" (a mensagem na tela)
Uma mensagem de erro na tela não é defeito por si. "Formato de e-mail inválido" é comportamento correto. O defeito é quando a mensagem está errada, falta, ou aparece quando não deveria. E o error de "Console error" é uma exceção registrada pelo runtime, que pode ou não ser defeito (muitos erros registrados são esperados e tratados). É por isso que um relato deve anexar a saída do Console em texto, não uma captura: quem triagem precisa do texto, da pilha e da frequência, não de uma imagem.Escolha um vocabulário e escreva
A recomendação com que a maioria dos times consegue viver:- Issue é o objeto no tracker. Todos os tipos vivem abaixo dele.
- Defeito é o tipo "comportamento errado" e a palavra de métricas, contratos e relatórios.
- Bug fica como palavra falada. Fora dos dashboards.
- Error / Fault / Failure apenas em análise de causa raiz, nessa ordem.
O que isso significa para o relato
Chame como quiser, os campos que a triagem precisa são idênticos:- a página ou endpoint exato,
- o que foi feito, o esperado e o que aconteceu,
- a evidência: print, erros de Console, requisições que falharam,
- o ambiente: navegador, OS, viewport, timestamp.