Skip to main content

Gerar Card de Bug

Objetivo desta página

Esta página define como registrar bugs de forma clara, técnica e rastreável na DBSeller, garantindo que qualquer pessoa do time consiga:

  • reproduzir o problema

  • entender o impacto

  • corrigir sem retrabalho

  • validar a correção com segurança

Um bug bem escrito já resolve metade do problema.

Quando abrir um bug

Um bug deve ser aberto sempre que o sistema:

  • se comportar diferente do esperado

  • violar regra de negócio

  • apresentar inconsistência de dados

  • quebrar fluxo existente

  • gerar erro, travamento ou comportamento inesperado

⚠️ Importante:
Bug não é sugestão de melhoria e não é dúvida de regra.
Se o comportamento está errado frente ao esperado, é bug.

Padrão de escrita de Bug (oficial DBSeller)

Este é o padrão obrigatório para abertura de bugs, devendo ser seguido em todos os registros.

🛠 [Empresa] – [Módulo] – [Resumo curto do problema]

O que é

O título do bug. Ele deve permitir que qualquer pessoa entenda o problema sem abrir o card.

Como usar

  • iniciar sempre com o nome da empresa

  • informar o módulo funcional afetado

  • descrever o problema de forma curta, direta e objetiva

Boas práticas

  • evitar termos genéricos como “erro”, “problema”, “não funciona”

  • focar no efeito visível do bug

Exemplo correto
Guarda – Cotações – Taxa exibida no front não corresponde à taxa aplicada no cálculo

Exemplo incorreto
Erro no sistema
Problema na cotação

🛠 Status: Aberto | Em Análise | Em Correção | Fechado

O que é

Indica a situação atual do bug no fluxo de correção.

Boas práticas

  • bug novo sempre começa como Aberto

  • status não representa prioridade

  • evitar usar status para indicar urgência

Status existe para controle de fluxo, não para pressão.

📌 Severidade: S1 | S2 | S3 | S4

O que é

Indica o impacto técnico e funcional do bug no sistema.

Classificação recomendada

  • S1 – Crítica: sistema quebrado, dados incorretos, impacto financeiro, bloqueio total

  • S2 – Alta: funcionalidade importante com comportamento incorreto

  • S3 – Média: inconsistências, problemas visuais ou mensagens incorretas

  • S4 – Baixa: ajustes cosméticos ou baixo impacto

⏳ Prioridade: Alta | Média | Baixa

O que é

Indica a urgência de correção do bug.

Ponto crucial

Severidade ≠ Prioridade

Um bug pode ser:

  • severidade média

  • prioridade alta

Exemplo: bug visual em tela crítica de cliente em produção.

📌 Pré-requisitos

O que é

Condições necessárias antes de executar os passos de reprodução.

Quando usar

Sempre que o bug não ocorre em um cenário genérico.

Exemplos comuns

  • usuário ADMIN

  • empresa com parâmetro específico

  • dado previamente cadastrado

  • lote já processado

Exemplo

  • Usuário com perfil ADMIN

  • Empresa sem o parâmetro “Habilitar consulta de Score de Endereços”

  • Lote previamente enviado no uploader

Pré-requisitos evitam o clássico: “não consegui reproduzir”.

📌 Passos para reprodução

O que é

Sequência exata para reproduzir o bug.

Boas práticas obrigatórias

  • sempre numerado

  • uma ação por linha

  • sem explicação ou interpretação

  • descrever apenas ações

Exemplo

  1. Acessar o módulo de Cotações.

  2. Abrir uma cotação existente.

  3. Clicar em “Recalcular”.

  4. Aguardar o processamento.

🚨 Resultado obtido

O que é

Descreve o que acontece hoje no sistema.

Regras obrigatórias

  • sempre usar ❌

  • descrever o comportamento real

  • incluir mensagens, erros ou comportamentos inesperados

Exemplo
❌ O sistema entra em loop de recálculo.
❌ Os dados não são atualizados após o processamento.
❌ É necessário recarregar a página manualmente.

✅ Resultado esperado

O que é

Define como o sistema deveria se comportar corretamente.

Regras obrigatórias

  • sempre usar ✔

  • comportamento claro e verificável

  • não incluir solução técnica

Exemplo
✔ O recálculo deve ocorrer apenas uma vez.
✔ Após a finalização, os dados devem ser exibidos corretamente.

📂 Evidência

O que é

Prova visual ou técnica do problema.

Pode ser

Exemplo
JAM: https://jam.dev/c/xxxxxxxx

Bug sem evidência sempre gera dúvida.

🧠 Possível causa e sugestões

O que é

Hipótese técnica do QA para acelerar a análise do dev.

Importante

  • não precisa estar correta

  • não é obrigação

  • não substitui análise técnica

Exemplo

  • evento de recálculo sendo disparado mais de uma vez

  • falha no controle de estado do frontend

  • falta de sincronização entre backend e UI

⚠️ Observações importantes (opcional)

Quando usar

  • bugs recorrentes

  • bugs de regressão

  • relação com outras tasks

  • regras de negócio sensíveis

Exemplo
Este bug começou a ocorrer após a alteração recente no processo de match.

🧩 Resumo mental do fluxo de um bom bug

Pré-requisitos → garantem o cenário
Passos → reproduzem
Resultado obtido → mostra o erro
Resultado esperado → define o correto
Evidência → comprova
Possível causa → acelera a correção

Erros comuns ao abrir bugs

  • título genérico

  • passos incompletos

  • ausência de evidência

  • misturar solução com problema

  • não diferenciar severidade de prioridade

Evitar esses erros reduz retrabalho e ruído no processo.

Resultado esperado deste padrão

Ao seguir este padrão, a DBSeller garante:

  • bugs claros

  • correções mais rápidas

  • menos retrabalho

  • validações mais eficientes

Gerar um bom card de bug é parte fundamental da qualidade, não apenas um registro de erro.

Back to top