Um bug marcado como "Fixed" que vai direto para "Closed" sem passar por "Verified" é como regressões chegam à produção. Um bug parado em "Assigned" por três sprints é um ticket que ninguém está acompanhando, não uma correção em andamento.

Os estados padrão e quem é responsável em cada um

Todo sistema de rastreamento de bugs tem seus próprios rótulos, mas os estados subjacentes são universais. Saber quem tem responsabilidade em cada etapa diz quando agir e quando esperar.

New é o momento em que você registra o ticket. Nada aconteceu ainda. O bug existe no papel mas ninguém se comprometeu a corrigi-lo. Seu trabalho aqui é tornar o relatório à prova de falhas: título claro, passos exatos de reprodução, resultado esperado versus atual, severidade, anexos. Um bug "New" mal escrito vai ficar no limbo do triage porque quem o pegar não vai conseguir reproduzir. Assigned significa que alguém do time de desenvolvimento é responsável pelo ticket. Não significa que olharam para ele. Não significa que concordam que é um bug. Significa que um nome está vinculado. Esse é o estado onde bugs envelhecem. Mais sobre isso em breve. In Progress significa que há trabalho ativo em andamento. Um desenvolvedor está reproduzindo, investigando ou escrevendo uma correção. Como QA, seu trabalho aqui é disponibilidade: se o desenvolvedor tiver perguntas sobre o ambiente de reprodução ou edge cases, responda rápido. Atrasos aqui adicionam lentidão ao sprint. In Review significa que a correção está escrita e aguardando revisão de código ou aprovação. Alguns times combinam isso com um estado "Ready for QA" que sinaliza que o build está disponível para verificação. Saiba qual fluxo seu time usa, porque a distinção importa para o seu planejamento de sprint. Fixed (ou "Ready for Testing") é o handoff de volta para você. O desenvolvedor acredita que o problema está resolvido. Agora é a sua vez. Verifique contra os passos de reprodução originais exatamente. Não improvise um novo caminho de teste. Confirme primeiro que o cenário específico que foi registrado está resolvido, depois expanda para casos relacionados. Verified significa que você confirmou que a correção funciona conforme descrito. O defeito original sumiu. Você verificou os caminhos de regressão óbvios. Esse estado é o seu sign-off. Closed significa que o bug verificado foi aceito e está concluído. Na maioria dos times, isso é feito pelo QA lead, pelo scrum master, ou acontece automaticamente quando o sprint fecha. Um bug nunca deve ir de Fixed para Closed sem passar por Verified. Pular essa etapa é como regressões chegam à produção.

O estado Rejected significa que o time decidiu que o comportamento reportado é na verdade correto. O resultado esperado no bug report estava errado, o comportamento é intencional por design, ou quem reportou entendeu mal o requisito. Rejected não significa que você foi descuidado. É um resultado legítimo. Documente por que foi rejeitado para que testadores futuros não registrem o mesmo ticket.

Deferred significa que o bug é real e reconhecido, mas não será corrigido neste sprint ou release. Vai para o backlog. Se algum dia será corrigido depende de quão bem você argumentar por ele. Won't Fix é o Deferred permanente. O time decidiu que esse defeito não vale o esforço de resolver. Às vezes essa é a decisão certa. Às vezes não é. Como você responde determina se isso se torna um problema mais tarde.

Won't Fix e Deferred: como argumentar sem perder

Um cenário real. Você registra um bug: "Na página de checkout, aplicar um código de desconto depois de selecionar um método de envio redefine a seleção de envio para a opção padrão." O PM faz o triage e marca como Deferred. O comentário: "Baixo impacto, edge case, poucos usuários são afetados."

É aqui que a maioria dos QA engineers ou aceita silenciosamente ou argumenta emocionalmente. Nenhum dos dois é eficaz.

A abordagem melhor é reformular a conversa em torno de dados e caminhos do usuário, não da sua opinião pessoal. Pergunte: quantas sessões de checkout por semana incluem um código de desconto? Seu analytics mostra picos de abandono nessa etapa? O reset de envio está causando pedidos enviados para o endereço errado?

Se você não tem esses dados, diga isso e pergunte quem pode obtê-los. "Gostaria de entender a frequência real antes de fecharmos isso. Podemos puxar dados do funil de checkout dos últimos 30 dias?" Essa é uma solicitação razoável, não uma briga.

Se o PM ainda quiser deferir depois de ver os dados, documente o risco explicitamente no ticket. Escreva: "Risco aceito: usuários aplicando códigos de desconto podem selecionar inadvertidamente o método de envio errado. Impacto: possível erro de fulfillment." Depois feche. Você fez seu trabalho. Se o problema escalar após o release, há um registro claro de que o risco foi levantado e documentado.

Para bugs Won't Fix que envolvem integridade de dados ou segurança do usuário, sempre adicione a declaração de risco antes de fechar. Uma nota de risco de uma linha protege tanto você quanto o time de produto se o problema ressurgir após um release.

Reabrindo bugs sem criar drama

Um bug volta. Você verificou há duas semanas, está em Closed, e agora o mesmo sintoma está aparecendo em produção. Você precisa reabri-lo, mas o desenvolvedor que corrigiu vai notar, e ninguém gosta de ver seu trabalho chamado de volta.

A regra é simples: reabra apenas quando você conseguir demonstrar que o cenário original está falhando novamente. Não "algo similar", não "pode estar relacionado". Os passos exatos de reprodução originais, mesmo ambiente, mesmo resultado.

Ao reabrir, adicione um comentário antes de mudar o estado. Inclua: a data em que está reabrindo, um novo screenshot ou gravação, e os passos exatos de reprodução que você executou (mesmo que idênticos ao original). Adicione também se está vendo o mesmo sintoma ou uma nova variação. Se for uma nova variação no mesmo componente, é um bug diferente, não um reabertura.

Digamos que você verificou que o bug do desconto-que-reseta-envio foi corrigido na v2.8.1. Na v2.8.3, depois de uma nova feature ser publicada no fluxo de checkout, o bug voltou. Você reabre, anexa uma gravação, e anota: "Regressão introduzida na v2.8.3. Correção verificada presente no build v2.8.1, não está mais presente no build atual. Reabrindo com nova gravação."

Esse enquadramento faz duas coisas. Ele reconhece que a correção original foi válida. Ele aponta para uma nova regressão em vez de implicar que o desenvolvedor não corrigiu direito da primeira vez. Essa distinção importa para o relacionamento de trabalho.

Bugs duplicados: identificação e merge elegante

Em qualquer produto ativo, múltiplos testers podem registrar o mesmo bug independentemente, especialmente em torno de features que acabaram de publicar. Identificar duplicatas cedo economiza tempo de triage e previne esforço dividido dos desenvolvedores.

Antes de registrar um novo bug, pesquise no seu tracker pelo sintoma. Pesquise por componente primeiro (checkout, login, upload), depois por palavras-chave da mensagem de erro ou do comportamento. Se você trabalha no Jira, use o painel "Similar Issues": ele pesquisa automaticamente quando você está criando um ticket.

Se encontrar uma duplicata depois de registrar, marque a sua como duplicata do original (não o contrário, a menos que a sua seja claramente mais detalhada). Adicione um comentário: "Marcando como duplicata de PROJ-144. Mesmo caminho de reprodução, mesmo sintoma. Adicionando meus screenshots ao ticket original para ajudar."

Depois vá ao ticket original e adicione de fato o valor da sua duplicata. Talvez a sua versão tenha um vídeo mais limpo ou uma versão diferente do navegador que reproduz o problema. Essa informação é útil mesmo que seu ticket seja fechado como duplicata.

Uma coisa a evitar: fazer merge de bugs que parecem iguais mas não são. Se dois tickets têm a mesma mensagem de erro mas triggers diferentes, podem ser dois defeitos separados. Verifique a causa raiz antes de fazer o merge. Um desenvolvedor que corrige um bug com base em um relatório combinado e perde o segundo trigger não fica feliz ao descobrir isso em produção.

Envelhecimento de bugs: o que fazer quando Assigned não significa nada

Você registrou um bug. Ele vai para o triage, é atribuído a um desenvolvedor, e então nada acontece por três sprints. A sprint review vem e vai, sem menção a ele. O ticket fica em "Assigned" como um fóssil.

Essa é uma das frustrações mais comuns em QA, e a resposta correta é visibilidade, não importunar.

Primeiro, olhe o bug por conta própria. A prioridade está correta? Ainda é bloqueante para algo? Se o contexto mudou e o bug é menos relevante agora, ajuste a prioridade e adicione um comentário. Um bug de baixa prioridade parado por três sprints é menos alarmante do que um de média prioridade.

Se a prioridade está correta e o bug ainda importa, leve-o para a sprint review explicitamente. Não como reclamação, mas como item de risco. "Temos o PROJ-188 parado em Assigned há três sprints. Afeta a feature de exportação CSV, que nossos usuários enterprise sinalizam com frequência. Quero sinalizá-lo para o próximo sprint antes que vire uma escalada de cliente."

A maioria dos bugs envelhecidos morre porque ninguém os trouxe de volta à tona. Suas reuniões de sprint review e refinamento de backlog existem exatamente para isso.

Nunca vá diretamente a um desenvolvedor perguntar por que um bug não foi corrigido. Isso cria atrito e ignora o processo do time. Levante bugs envelhecidos no nível do time durante as cerimônias do sprint.

Se o bug genuinamente não deveria ser corrigido no roadmap atual, peça que seja formalmente Deferred com um motivo documentado. Um Deferred honesto é melhor do que um ticket Assigned zumbi: ele dá ao time um sinal claro e evita impressões falsas sobre a contagem de bugs abertos.

Jira vs Linear vs GitHub Issues em 2026

A lógica de fluxo de trabalho acima se aplica em todos, mas as ferramentas em que você trabalha têm diferenças significativas em como implementam transições de estado.

Jira continua sendo o padrão em times enterprise de médio a grande porte. Em 2026, está na terceira geração de fluxos de trabalho desde a divisão company-managed vs team-managed. Estados de bugs no Jira são totalmente customizáveis, o que significa que cada time usa um subconjunto diferente dos estados descritos acima. Sua primeira semana em um novo time usando Jira deve incluir entender exatamente o que os estados do fluxo deles significam. Não assuma que "In Progress" significa que um desenvolvedor está ativamente trabalhando. Em algumas configurações do Jira significa "reconhecido mas não iniciado." Verifique a documentação do fluxo ou pergunte diretamente. Linear agora é padrão na maioria das startups em estágio inicial e de crescimento. Usa um modelo de estado mais simples: No Status, Backlog, Todo, In Progress, In Review, Done, Cancelled. Não há estado dedicado de "Verified" por padrão: a verificação de QA acontece dentro de "In Review" ou os times adicionam um estado customizado. Se você for entrar em um time usando Linear, verifique se eles têm uma etapa de verificação de QA no fluxo. Se não tiverem, proponha uma. Um ticket indo de "In Review" para "Done" sem um tester dar sign-off é um padrão que eventualmente publica correções não verificadas. GitHub Issues é comum em produtos open-source e de tooling para desenvolvedores. Seu modelo de estado nativo é apenas Open e Closed, com labels para todo o resto. A maioria dos times que faz QA estruturado no GitHub Issues usa labels como status: ready for QA, status: verified, e milestones para rastrear o escopo do release. O atrito aqui é que o GitHub Issues não tem fluxo forçado: a disciplina é totalmente manual. Em um time que falta essa disciplina, bugs vão de Open para Closed sem nenhuma etapa de verificação.

O fio comum: qualquer que seja a ferramenta, entenda o fluxo real que seu time usa, não o que a ferramenta suporta por padrão. Os estados do ciclo de vida existem independentemente de quais rótulos seu tracker usa.

Métricas: os números que dizem se o processo está funcionando

Rastrear estados de bugs individualmente é útil. Rastrear padrões em todos os bugs diz se o seu processo de qualidade está saudável.

Taxa de escape de defeitos mede a porcentagem de bugs encontrados em produção versus bugs encontrados antes do release. Se seu time está encontrando 30% dos bugs após o release, o processo de testes não está capturando o suficiente antes de o software publicar. A fórmula: (bugs encontrados pós-release) / (total de bugs encontrados) × 100. Uma taxa saudável para a maioria dos times é abaixo de 15%. Se a sua for maior, olhe onde no ciclo de desenvolvimento os bugs estão sendo introduzidos e onde a cobertura de testes termina. Tempo médio para resolver (MTTR) mede o tempo médio desde o registro de um bug até ele ser fechado. Um MTTR crescente sinaliza uma de três coisas. O time está subestimado para o volume de bugs. Os bugs estão sendo registrados com qualidade menor, levando mais tempo para triage e reprodução. Ou componentes específicos estão gerando densidade de defeitos desproporcional. Rastreie o MTTR por componente para encontrar os pontos quentes. Relatório de envelhecimento de bugs abertos é exatamente o que parece: uma visão de todos os bugs abertos ordenados por quanto tempo estão abertos, agrupados por estado. A versão útil desse relatório segmenta por estado. Um acúmulo em "New" significa que o triage está atrasado. Um acúmulo em "Assigned" significa que os desenvolvedores não estão pegando os bugs. Um acúmulo em "Fixed" significa que o QA não está verificando rápido o suficiente. Cada estado conta uma história diferente sobre onde está o gargalo.

Essas três métricas juntas dão uma visão razoavelmente completa da saúde do ciclo de vida do bug. Execute-as mensalmente, não apenas no final de um ciclo de release.

Como aplicar isso na segunda-feira de manhã

Abra seu bug tracker e puxe todos os tickets atribuídos a você ou registrados por você que não estão em Closed ou Won't Fix. Para cada um: está no estado correto? A prioridade ainda está precisa dado o que você sabe sobre o sprint atual? Algum ticket ficou no mesmo estado por mais de dois sprints sem um comentário?

Para cada ticket envelhecido, adicione um comentário de uma linha hoje. Se ainda relevante, escreva uma verificação de status: "Ainda relevante: feature de exportação ainda está no escopo, levantando para a próxima sprint review." Se não for mais relevante, peça para Defer: "Contexto mudou desde o registro: essa tela foi removida na v2.9. Recomendando fechar."

Essa única passagem pelos seus bugs abertos faz três coisas: limpa seu backlog mental, dá ao time informações precisas sobre o que realmente está aberto, e demonstra que você está gerenciando ativamente a qualidade, não apenas registrando tickets e seguindo em frente.

O ciclo de vida do bug não é burocracia. É o mecanismo pelo qual uma descoberta vira uma correção. Cada transição de estado é um handoff, e cada handoff precisa de alguém prestando atenção nele. Esse é o trabalho.

→ Veja também: A Anatomia de um Bug Report que os Desenvolvedores Realmente Corrigem | Severity vs Priority: A Habilidade de Triage que Promove Junior QAs | Como Escrever um Caso de Teste: Formato, Exemplos e Erros Comuns