A triagem de bugs é o trabalho entre «chegou um relatório» e «alguém está corrigindo». A maioria das equipes não é lenta na parte de decidir. É lenta em tudo o que fica em volta.
Observe uma rodada normal. Abra um relatório. Leia. Volte para a lista. Ache onde você estava. Abra o próximo. Volte de novo. Cada decisão leva segundos; a navegação come o resto dos dez minutos. Pior: cada ida e volta é uma pequena troca de contexto, e muitas delas transformam a triagem naquela tarefa chata que fica para depois até o backlog ficar ilegível.
Este é um fluxo que tira a navegação do caminho, em vez de pedir que alguém pense mais rápido.
O que é, de fato, a triagem de bugs
A triagem faz três perguntas a cada relatório que chega:
Isso é novo? Ou é o quadragésimo relatório de algo para o qual você já tem uma tarefa.
É real? Reproduzível, ou sustentado por evidências conclusivas o bastante para agir.
Quão urgente é? Em relação a todo o resto que está aberto, não isoladamente.
Todo o resto (atribuir, etiquetar, escrever os passos para reproduzir, chamar a pessoa responsável por aquela parte do código) decorre dessas três respostas. Uma sessão de triagem que produz respostas está funcionando. Uma que produz uma lista maior de coisas para ver depois, não.
A ida e volta é o custo real
Um relatório só vale a pena ser lido com contexto: a descrição, os erros do console em volta, a requisição que falhou, o navegador e a viewport, o que o usuário clicou nos segundos antes de quebrar. Esse contexto fica numa tela de detalhes.
Então o ciclo vira lista, detalhe, lista, detalhe. Cada salto recarrega uma página, perde a posição de rolagem e esquece em que item você estava. Dez relatórios são vinte navegações, e no sexto você já parou de ler com atenção.
A solução não é uma página mais rápida. É nem sair da lista.
Trabalhe uma coluna por vez
Antes de abrir qualquer coisa, reduza o quadro a uma única fila. No BugDump, isso significa filtrar por uma prioridade, um navegador ou um texto e depois trabalhar uma única coluna de cima a baixo.
Duas coisas acontecem quando você faz isso. A fila ganha um fim definido, e é isso que torna uma sessão algo que se termina, em vez de algo sem fim. E cada tarefa da fila é comparável à anterior, então a prioridade relativa deixa de ser chute: você não está mais pesando, ao mesmo tempo, um bug crítico no checkout e um erro de digitação num texto.
Uma coluna também é como o olho já lê um quadro. Trabalhar atravessando colunas significa se reorientar o tempo todo.
Avance, não navegue
Abra o primeiro cartão. Em vez de uma página nova, a tarefa abre num painel ao lado do quadro: descrição, cada relatório anexado com seus logs de console e de rede, comentários e os controles de status, responsável e prioridade.
Depois, largue o mouse. J vai para a próxima tarefa daquela coluna. K volta. Leia, defina a prioridade, atribua, mova, aperte J. O quadro nunca recarrega e nunca perde a posição, então o ciclo se reduz a uma tecla entre uma decisão e outra.
Dois detalhes importam mais do que parece:
O avanço fica dentro da coluna em que você começou. Ele para nas pontas, em vez de dar a volta ou passar para a coluna seguinte, então terminar uma coluna é um acontecimento de verdade, e não algo que você percebe três tarefas depois.
O avanço segue os filtros. Filtre pelos bugs críticos e «Próxima tarefa» só passa por bugs críticos. A fila que você definiu é a fila que você percorre.
Os atalhos também saem do caminho enquanto você digita, então um j num comentário é um j num comentário.
Agrupe as decisões que já são óbvias
Parte da triagem nem precisa de leitura. Um deploy ruim gera trinta relatórios da mesma falha. Uma onda de spam gera vinte relatórios de nada.
Não avance por eles um a um. Selecione os cartões direto no quadro (Cmd ou Ctrl + clique para escolher um por um, Shift + clique para um intervalo) e mova ou exclua a seleção inteira de uma vez.
A regra prática: se você já sabe a resposta antes de abrir a tarefa, ela vai para um lote. Avançar uma a uma é para os relatórios que pedem julgamento, e o objetivo dos lotes é garantir que eles recebam a sua atenção, e não o que sobrou dela.
Agrupar duplicatas primeiro é o hábito que mais rende na triagem. Ele costuma transformar quarenta itens da caixa de entrada em seis tarefas reais, e tudo o que vem depois fica mais barato. O guia de fluxo de triagem cobre a rotina diária completa.
Passe adiante com um link, não com uma descrição
A triagem termina com o trabalho indo para outra pessoa, e é aí que o tempo economizado costuma vazar de volta. Redigitar um bug no Slack (meio resumo, passos aproximados para reproduzir, uma captura de tela) é mais lento que a própria triagem e perde mais informação que o relatório que você acabou de ver.
Copie o link da tarefa. Um link carrega a descrição, cada relatório anexado, a saída do console, a atividade de rede, o ambiente e a discussão até ali. Quem recebe vê o que você viu, e não a sua lembrança disso.
Se a sua equipe depura com um assistente de IA, basta passar o mesmo ID público: aponte o Claude Code para a tarefa via MCP e ele lê os relatórios, os logs e os traces direto, em vez de alguém contar para ele.
Com que frequência fazer uma rodada
De dez a quinze minutos, uma vez por dia. Duas ou três vezes por dia numa semana de lançamento.
Fazer todo dia importa mais do que fazer por muito tempo. A dívida de triagem se acumula de um jeito específico: quanto mais velho o relatório, mais difícil reproduzir, maior a chance de quem relatou ter ido embora e maior a chance de ele duplicar algo que chegou depois. Um backlog que você pula por uma semana não é o mesmo backlog uma semana depois. É um backlog pior.
As falhas que vale a pena nomear
Fazer a triagem na ordem da caixa de entrada. Ordem de chegada não é ordem de importância. Filtre primeiro, depois trabalhe uma fila.
Ler tudo antes de decidir qualquer coisa. Uma rodada em que nada muda de coluna não aconteceu.
Uma coluna «Precisa de informações». Ela vira o lugar para onde as tarefas vão para ser esquecidas. Pergunte a quem relatou agora ou feche.
Tudo é crítico. Um backlog em que toda tarefa é urgente carrega exatamente tanta informação quanto um em que nenhuma é.
Nunca fechar nada. A falha de triagem mais comum não é priorizar errado; é um número de abertos que só cresce até o quadro deixar de descrever a realidade.
Experimente no seu quadro
Se você já usa o BugDump, o fluxo está disponível agora: filtre o quadro, clique no primeiro cartão e use J e K para percorrer a coluna. Veja como trabalhar com tarefas e com o quadro para os outros controles do painel.
Leia também
Como escrever um bom relatório de bug (com checklist) — o que falta na maioria dos relatórios de bug e como garantir que os detalhes que importam cheguem junto.
De 40 relatórios a 6 bugs: como a triagem deveria funcionar — por que separar relatórios de tarefas e como as duplicatas viram material de depuração.
Métricas de bugs que importam de verdade — quatro números que mostram se a equipe está dando conta e uma revisão semanal de cinco minutos montada em cima deles.