O bug triage é o processo de confirmar, classificar e atribuir os defeitos recém-reportados, para que os recursos escassos de desenvolvimento vão primeiro para os problemas de maior impacto. Um processo de triagem eficaz garante duas coisas: cada defeito é olhado dentro de um prazo fixo, e uma vez olhado, o destino dele fica decidido (consertar, agendar, rebaixar ou fechar).
Por que a triagem existe
Times sem mecanismo de triagem costumam exibir uma de duas patologias:
- Lei da voz mais alta: quem reclama mais alto é atendido primeiro; P0 e P2 ficam na mesma fila;
- Buraco negro: os defeitos se espalham por chats, e-mails e feedback verbal, e uma boa parte nunca foi "decidida" por ninguém.
A triagem existe para dar a todos os defeitos uma entrada única e um ponto de decisão: cada item que entra é verificado em 24 horas, recebe severidade e prioridade, e ganha dono.
Os papéis na triagem
| Papel |
Responsabilidade |
| Facilitador da triagem (normalmente o QA lead) |
Conduz a reunião de triagem, mantém a fila em zero, empurra as decisões |
| QA / testores |
Verificam a reprodutibilidade, completam os passos de reprodução, classificação preliminar |
| Líder de desenvolvimento |
Avalia o impacto técnico, estima o custo de correção, aceita as atribuições |
| Product owner (PM/PO) |
Define a prioridade de negócio, decide as brigas de "consertar ou não" |
Times pequenos podem juntar QA lead e PM numa pessoa só — mas as duas perspectivas, julgamento técnico e julgamento de negócio, precisam estar presentes.
O fluxo padrão de triagem (5 passos)
1. Receber e deduplicar
Os relatórios de todos os canais (testes internos, usuários beta, feedback de produção) aterrissam no mesmo registro e são mesclados após deduplicação por "módulo + sintoma". Entradas dispersas são a raiz do fracasso da triagem — o bug reportado no chat e o reportado na ferramenta precisam acabar numa única tabela.
2. Validar
- Reproduzível? Percorre os passos do relatório;
- Não reproduz: anota as informações do ambiente e devolve ao reportante para completar — times cujos relatórios trazem o contexto do ambiente quase não travam aqui (ver abaixo);
- Não é defeito (comportamento esperado / dúvida de uso): converte em pergunta de suporte ou melhoria de documentação, fecha e avisa o reportante.
3. Classificar (Severidade × Prioridade)
Severidade (visão técnica) e prioridade (visão de negócio) são duas dimensões; não misture:
| Prioridade alta |
Prioridade baixa |
| Severidade alta |
Consertar já (página inicial fica branca) |
Consertar neste sprint (uma função de cauda quebra, sem plano B, mas quase ninguém chega lá) |
| Severidade baixa |
Consertar em breve (botão de login desalinhado, atinge todo usuário) |
Para o backlog (um erro de digitação num canto da página) |
O erro comum é assumir "severidade = prioridade": assim uma pilha de problemas "não fatais tecnicamente mas embaraçosos para o negócio" fica para sempre na fila da fome.
4. Atribuir e agendar
- P0: hotfix ou rollback no mesmo dia, avisar todos os envolvidos;
- P2/P3: para o Product Backlog, ordenados como sempre.
5. Devolver e fechar
Depois da correção: pedir ao reportante (sobretudo se for testor externo) que reverifique → verificação passou → fechar e registrar a categoria da causa raiz (para as estatísticas da retrospectiva). Devolver o status ao reportante externo decide diretamente se ele vai reportar de novo.
Como conduzir a reunião de triagem
- Frequência: times de iteração rápida se reúnem todo dia, 15–30 minutos, só itens novos; ritmos mais lentos, 2–3 vezes por semana;
- Formato: percorrer o quadro do registro, 3–5 minutos por item; o que não se decidir em 5 minutos vai para "pendente" e se resolve num 1:1 antes do fim do dia;
- Disciplina: a reunião decide, não desenha solução técnica; só itens novos, o que já foi classificado não se renegocia.
O pré-requisito da triagem rápida: relatórios que vêm com contexto
A cena que mais desperdiça tempo numa reunião de triagem: o QA lê um relatório — "o usuário diz que o botão não faz nada" — e todo mundo começa a perguntar: qual página? qual navegador? tem erro no Console? consegue clicar de novo? Um relatório que devia levar 2 minutos para classificar vira um policial de 15.
A causa raiz é o relatório sem contexto. Compare:
| Informação |
Relatório manual (usuário narrando de memória) |
Relatório coletado automaticamente |
| Passos de reprodução |
"Cliquei naquele botão e não aconteceu nada" |
Captura/gravação anotada apontando o lugar e a ação |
| URL da página |
Costuma faltar ou vir errada |
Anexada automaticamente |
| Navegador/dispositivo |
Normalmente falta |
Anexado automaticamente |
| Erros Console / Network |
Praticamente impossível |
Stack traces de ERROR e requisições falhas anexadas |
A coluna da direita não é fantasia — é exatamente como o BugCapturer funciona: quando os usuários (incluindo beta testers totalmente leigos) enviam feedback, o relatório carrega automaticamente a captura/gravação anotada, a URL, o ambiente do navegador e os erros Console/Network (veja a função de diagnóstico). Na reunião de triagem percorre-se o registro, 2 minutos para classificar cada item; a parcela de "não reproduz" na validação cai de forma visível. Os relatórios são enviados automaticamente a um canal do Slack / Microsoft Teams para acompanhamento unificado — a deduplicação e as estatísticas ganham uma única fonte da verdade.
Métricas de autocrítica da qualidade da triagem
| Métrica |
Valor saudável |
Significado |
| Primeira resposta a um relatório |
< 24 h |
Do envio até a decisão de triagem |
| Acúmulo de "pendentes" |
< 5 % |
Pendentes que envelhecem = critérios de classificação confusos |
| Taxa de relatórios duplicados |
caindo |
O registro e a deduplicação funcionam |
| Número de P0 |
caindo |
Persistente alto = falta atividade de qualidade a montante |
| Taxa de reverificação dos reportantes |
alta |
Satisfação e retenção dos testores externos |
Essas métricas também alimentam a retrospectiva do sprint — veja "Sustente a retro com dados" no guia de sprint retrospective.
FAQ
P: O que é defect triage?
R: O processo de decisão para os defeitos novos: validar, deduplicar, classificar (severidade × prioridade), atribuir. Costuma ser executado como reunião de triagem em cadência fixa, com QA, dev e produto juntos.
P: Bug triage vs bug tracking — qual a diferença?
R: O tracking é a ferramenta e o mecanismo para registrar e acompanhar o status dos defeitos; a triagem é o processo que toma uma decisão de tratamento por defeito. O registro é o tracking; a triagem é a camada de decisão que roda sobre o registro.
P: Um time pequeno precisa de processo de triagem?
R: Precisa, mas mínimo: sem reunião; o QA lead dedica 15 minutos fixos por dia para percorrer o registro, classificar e atribuir. O que importa é o resultado — cada defeito foi explicitamente decidido.
P: O reportante não é técnico, como garantir relatórios utilizáveis?
R: Não peça detalhes técnicos ao reportante; colete automaticamente. Ferramentas como o BugCapturer anexam URL, ambiente e erros Console/Network no envio — até relatórios de leigos podem ser triados direto.
P: Quando severidade e prioridade brigam, quem ganha?
R: A prioridade é a ordem final de execução, decidida pelo product owner na reunião de triagem; a severidade é um insumo técnico que informa a decisão, não um substituto.