Triagem de Bugs no Jira: Qualidade do Registro, Severidade e Priorização

Objetivo da triagem de bugs

A triagem é o processo de avaliar rapidamente um bug registrado para decidir: (1) se o registro tem qualidade suficiente para ser trabalhado, (2) se o problema é válido (de fato um defeito), (3) qual o impacto e urgência (severidade e prioridade), e (4) qual o próximo passo (corrigir, pedir mais informações, fechar com motivo adequado). O foco é reduzir retrabalho e acelerar decisões, mantendo rastreabilidade do porquê cada bug foi aceito, rejeitado ou encerrado.

Bug válido: critérios objetivos para aprovação

Antes de discutir prioridade, confirme se o bug é válido. Use critérios simples e auditáveis:

• Existe comportamento observável: há um resultado obtido claro, não apenas uma opinião (“tá estranho”).
• Existe referência do esperado: requisito, história, regra de negócio, protótipo, contrato de API, padrão de UX, ou comportamento anterior conhecido.
• É reprodutível (idealmente): pode ser reproduzido com passos e ambiente definidos. Se não for, ainda pode ser válido, mas exige evidências e contexto mais fortes.
• Não é duplicado: já existe bug aberto para o mesmo problema (mesmo sintoma/causa/escopo).
• Não é “já corrigido”: o problema não está resolvido na versão/build alvo (ou já existe correção em andamento).
• Não é “funciona como projetado”: o comportamento está alinhado ao esperado documentado.

Checklist rápido de validade (triagem em 2 minutos)

• Consigo entender o problema em uma leitura?
• Consigo reproduzir com os passos e ambiente descritos?
• Existe evidência (print, vídeo, log) que confirme o obtido?
• Existe referência do esperado?
• Já existe issue igual?
• O escopo afetado está claro (módulo, tela, endpoint, perfil)?

Severidade vs Prioridade (e como não confundir)

Severidade (impacto técnico/funcional)

Severidade mede o tamanho do dano causado pelo bug: o quanto ele quebra o sistema, a experiência, a segurança ou a integridade dos dados.

• Crítica: impede uso do produto/fluxo principal, causa perda/corrupção de dados, falha de segurança, crash recorrente, indisponibilidade.
• Alta: quebra funcionalidade importante, sem alternativa viável, impacto significativo em muitos usuários.
• Média: problema relevante, mas com contorno (workaround) ou impacto limitado.
• Baixa: detalhe de UI, texto, alinhamento, pequena inconsistência sem impacto funcional.

Prioridade (urgência de correção)

Prioridade define quando corrigir, considerando contexto de entrega: risco de release, volume de usuários afetados, custo de atraso, dependências e compromissos.

• P0: corrigir imediatamente (bloqueia release ou operação).
• P1: corrigir no ciclo atual (alto risco/visibilidade).
• P2: corrigir quando possível (planejar).
• P3: backlog (baixo retorno/urgência).

Exemplos práticos (severidade ≠ prioridade)

Fatores de triagem: impacto, frequência, reprodutibilidade e escopo

Impacto

• Usuário: impede tarefa? gera frustração? afeta acessibilidade?
• Negócio: afeta conversão, receita, SLA, compliance?
• Dados: há risco de perda, duplicidade, inconsistência?
• Segurança: exposição de dados, bypass de autenticação, permissões?

Frequência

Classifique com base em evidência e contexto:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Sempre: 100% nas condições descritas.
• Intermitente: ocorre às vezes; exige mais evidência (vídeo/logs) e tentativa de isolamento.
• Raro: difícil de reproduzir; pode exigir monitoramento/telemetria.

Reprodutibilidade

Um bug reprodutível acelera correção. Quando não for reprodutível, a triagem deve exigir: (1) evidência forte, (2) detalhes de ambiente, (3) tentativa de reduzir variáveis (conta, dados, horário, rede, cache).

Escopo afetado

• Onde: módulo/tela/endpoint/serviço.
• Quem: perfil de usuário, permissões, tenant/cliente.
• Quando: após atualização, em horário de pico, em condição específica.
• Plataformas: navegador/OS/app versão/dispositivo.

Campos e informações mínimas para aprovar um bug

Defina um padrão de “bug pronto para triagem/aprovação”. Abaixo está um conjunto mínimo de informações que reduz idas e vindas.

Estrutura recomendada de descrição

• Resumo (Summary): ação + problema + contexto. Ex.: “Checkout: cupom aplicado não reduz total no carrinho (web)”.
• Pré-condições: estado necessário (usuário logado, item no carrinho, permissão X).
• Passos para reproduzir: numerados e objetivos.
• Resultado obtido: o que aconteceu (inclua mensagens de erro).
• Resultado esperado: comportamento correto com referência (regra/requisito).
• Ambiente: versão/build, URL, navegador/OS/app, dispositivo, flags, dados relevantes.
• Evidências: prints/vídeo/logs/har, com indicação do ponto exato do problema.
• Impacto e frequência: sempre/intermitente, quantos usuários, bloqueia fluxo?
• Escopo: páginas, APIs, perfis, clientes afetados.

Modelo pronto (para colar no Jira)

Pré-condições: [ex.: usuário com perfil X, carrinho com 1 item, cupom ABC válido]  Passos para reproduzir: 1) ... 2) ... 3) ...  Resultado obtido: [descrever + mensagens/IDs]  Resultado esperado: [descrever + referência]  Ambiente: - Sistema: [web/app] - URL: - Versão/build: - Navegador/OS/dispositivo: - Feature flags/config: - Dados usados (IDs):  Evidências: - [link/anexo] - [log/console/har]  Frequência: [sempre/intermitente]  Escopo afetado: [módulo/tela/perfil/cliente]

Regras de aprovação (gate de qualidade)

• Obrigatório: passos + ambiente + esperado/obtido + evidência.
• Obrigatório quando aplicável: IDs (pedido, usuário, transação), horário do ocorrido, logs/console, payload/response.
• Se faltar: não “adivinhar”; devolver para complemento com perguntas objetivas.

Passo a passo prático de triagem no Jira

1) Leitura e normalização rápida

• Reescreva o resumo se estiver vago (sem mudar o sentido).
• Garanta que esperado/obtido estão explícitos.
• Confirme que há evidência anexada e que ela corresponde ao relato.

2) Verificar reprodutibilidade

• Tente reproduzir no ambiente indicado.
• Se reproduzir: registre no comentário “Reproduzido em…” com data, build e condições.
• Se não reproduzir: não feche imediatamente; siga o fluxo “falta info / cannot reproduce” com critérios (ver abaixo).

3) Checar duplicidade

• Busque por palavras-chave do resumo, módulo e mensagem de erro.
• Compare: mesmo sintoma? mesmo escopo? mesma causa provável?
• Se for duplicado: feche como Duplicate e vincule ao bug principal (mantendo rastreabilidade).

4) Checar se já foi corrigido

• Confirme versão/build alvo e se existe correção em release posterior.
• Se o bug não ocorre na versão mais recente do ambiente de validação: feche como “já corrigido” conforme política do time (ex.: Done com resolução “Fixed” e comentário indicando a versão).

5) Classificar severidade

• Use impacto em usuário/negócio/dados/segurança.
• Registre justificativa curta no comentário quando for Crítica/Alta (ajuda em auditoria e alinhamento).

6) Definir prioridade (com stakeholders quando necessário)

• Considere: risco de release, volume de usuários, SLA, dependências, custo de atraso.
• Se houver conflito (ex.: severidade alta, mas prioridade baixa): documente o motivo (ex.: feature flag, baixa exposição).

7) Encaminhar para o próximo responsável

• Atribua ao time correto (componente/módulo) e marque rótulos úteis (ex.: regression, production, intermittent).
• Se for necessário refinamento técnico: peça logs, IDs e janela de tempo.

Fluxo de triagem com decisões (árvore prática)

INÍCIO  ↓  Registro tem info mínima (passos + ambiente + esperado/obtido + evidência)?  ├─ NÃO → Solicitar informações (status “Need Info”/equivalente) + perguntas objetivas  └─ SIM  ↓  É reproduzível nas condições descritas?  ├─ SIM  ↓  Já existe bug igual?  │   ├─ SIM → Fechar como Duplicate + linkar ao bug principal  │   └─ NÃO  ↓  O comportamento é esperado (funciona como projetado)?  │       ├─ SIM → Fechar como “Not a Bug”/“Works as Designed” + referência  │       └─ NÃO  ↓  Já está corrigido na versão alvo/mais recente?  │           ├─ SIM → Fechar como Fixed (indicando versão/build)  │           └─ NÃO → Classificar severidade + definir prioridade + encaminhar para correção  └─ NÃO  ↓  Há evidência forte (vídeo/log/IDs) e contexto suficiente?      ├─ NÃO → Need Info (pedir dados para reproduzir)      └─ SIM → Manter aberto como “Cannot Reproduce” temporário ou “Investigate” (conforme política),          registrar tentativas e solicitar suporte técnico (logs/telemetria)

Perguntas objetivas para quando faltar informação

• Qual build/versão e URL?
• Qual usuário/perfil e quais IDs (pedido, cliente, transação)?
• Ocorre em qual navegador/OS/dispositivo?
• Ocorre sempre ou intermitente? Se intermitente, qual a taxa aproximada?
• Há vídeo do fluxo completo e/ou log (console, network, backend)?
• Quais pré-condições e dados necessários?

Como fechar bugs corretamente mantendo rastreabilidade

Fechar um bug não é “apagar o problema”; é registrar uma decisão com justificativa verificável. Sempre deixe um comentário curto com: (1) motivo, (2) evidência/critério, (3) links relevantes.

Fechamento: Duplicate

• Quando usar: o mesmo problema já está registrado e ativo.
• Como registrar: definir resolução Duplicate e adicionar link para o bug principal.
• Comentário sugerido:

Encerrado como Duplicate do BUG-123. Mesmo sintoma e mesmo escopo (tela X, perfil Y). Acompanhar correção no BUG-123.

Fechamento: Cannot Reproduce

• Quando usar: após tentativas documentadas, não foi possível reproduzir e não há dados adicionais suficientes, ou o problema parece ter sido transitório.
• Boas práticas: registre tentativas (ambiente, versão, data) e o que faltou para avançar (IDs, logs, vídeo).
• Comentário sugerido:

Não reproduzido em build 1.8.4 (staging), Chrome 121/Windows 11, seguindo os passos informados. Para reabrir, enviar: vídeo do fluxo + IDs (pedido/usuário) + horário aproximado + log de network/console.

Fechamento: Won’t Fix

• Quando usar: o bug é real, mas a decisão é não corrigir (custo alto, baixo retorno, mudança planejada, produto descontinuado, risco de regressão maior que o benefício).
• Obrigatório: justificar a decisão e, se aplicável, apontar alternativa (workaround) e/ou item de roadmap.
• Comentário sugerido:

Encerrado como Won’t Fix: impacto baixo e correção exige refatoração ampla no módulo X com alto risco de regressão. Workaround: orientar usuários a usar o filtro Y. Reavaliar na iniciativa Z (Q2).

Fechamento: Not a Bug / Works as Designed

• Quando usar: comportamento está correto conforme regra/requisito.
• Como manter rastreabilidade: cite a referência (regra, decisão, documentação interna) e, se necessário, sugerir melhoria como outro tipo de item.

Encerrado como Works as Designed: regra define que o desconto não se aplica a itens da categoria “Serviços”. Referência: regra de negócio RB-07.

Fechamento: Fixed (já corrigido)

• Quando usar: o bug não ocorre mais e há confirmação em versão específica.
• Comentário sugerido:

Validado como corrigido em build 1.8.6 (staging). Evidência: vídeo anexado mostrando fluxo completo sem erro.

Padrões de comentários que aceleram a triagem

• Reproduzido: “Reproduzido em [ambiente], [build], [plataforma], [condição].”
• Não reproduzido: “Não reproduzido em…, seguindo passos…, faltam… para avançar.”
• Decisão de prioridade: “Prioridade P1 devido a [risco/volume/SLA], apesar de severidade [x].”
• Escopo: “Afeta [módulo], [perfil], [cliente], [plataforma].”