Um bug que corrompe registros do banco de dados durante uma importação em massa é Crítico em severidade. Se essa importação roda uma vez no onboarding por um único administrador com um workaround disponível, ele pode legitimamente esperar até o próximo sprint. O nome de um parceiro escrito errado na homepage vai para um hotfix hoje. Severidade e prioridade são dimensões separadas.
O que severidade realmente significa
Severidade mede o impacto técnico do bug. Quão gravemente esse defeito danifica o sistema? Perda de dados, travamento, fluxo de pagamento quebrado: isso é alta severidade. Um label de botão desalinhado, um typo em um tooltip: baixa severidade.
Severidade vive puramente no domínio técnico. Não leva em conta o cronograma de release, a campanha de marketing, ou quantas pessoas vão ver. Responde uma pergunta: quão quebrado está isso, objetivamente?
A escala clássica de quatro níveis que a maioria dos times usa:
Crítico: o bug torna algo completamente não funcional, corrompe dados, cria uma vulnerabilidade de segurança ou trava a aplicação. O usuário não consegue prosseguir. Não existe workaround. Exemplo: clicar em "Fazer Pedido" mostra uma tela de sucesso, mas o pedido nunca é gravado no banco de dados. Maior: uma feature significativa está quebrada ou gravemente comprometida. O workaround existe, mas é inconveniente ou não óbvio. Exemplo: exportar um relatório para CSV produz um arquivo com encoding corrompido para qualquer nome que contenha um caractere não-ASCII. Menor: a funcionalidade funciona, mas algo está errado de uma forma que afeta a experiência do usuário sem impedir a tarefa. Exemplo: o email de confirmação de "Redefinir Senha" diz "Sua senha fui redefinida" em vez de "foi". Trivial: cosmético, impacto funcional negligenciável. Nenhum usuário está bloqueado. Exemplo: o ano de copyright no rodapé mostra 2024 em vez de 2026.Você, como QA, define a severidade. É seu julgamento profissional, e deve ser defensável com base no impacto observável, não em sentimentos.
O que prioridade realmente significa
Prioridade mede urgência de negócio. Com qual rapidez isso precisa ser corrigido, em relação a tudo mais no backlog?
Prioridade não é sua decisão sozinho. Um product manager, líder de engenharia ou dono do projeto normalmente é responsável pela prioridade. O cargo exige conhecimento do cronograma de release, compromissos de negócio e tolerância a risco que o QA frequentemente não tem.
Dito isso, sua avaliação de severidade alimenta diretamente a decisão de prioridade deles. Se você rotular a severidade errado, está alimentando dados ruins numa decisão de negócio.
Na prática, times pequenos misturam essas linhas. Um QA lead pode definir as duas em um bug. Tudo bem. O ponto central é manter o raciocínio separado: "isso é tecnicamente ruim por estes motivos" versus "isso precisa ir na sexta por estes motivos."
A matriz 2x2: onde fica interessante
Os casos óbvios são fáceis. Um travamento no checkout no fluxo principal de pagamento? Alta severidade, alta prioridade, corrija agora. Um pixel desalinhado numa página de admin que ninguém usa? Baixa severidade, baixa prioridade, pode esperar.
Os casos interessantes são os dois cantos que todo mundo ignora.
Alta severidade, baixa prioridade. Imagine que você está testando um aplicativo enterprise com uma feature de importação de dados em massa usada por administradores de banco de dados para migrar dados legados. Você encontra um bug: se o arquivo de importação contém uma coluna com valores nulos numa posição específica, ele corrompe o dataset importado.Isso é severidade Crítica. Corrupção de dados é tão ruim quanto pode ficar.
Mas a feature é usada uma vez no onboarding inicial por um único usuário técnico, sempre em condições supervisionadas. Um workaround existe: remover valores nulos daquela coluna antes de importar. O próximo release é daqui a um mês, e há cinco fluxos de maior tráfego com bugs ativos competindo pelo tempo dos desenvolvedores.
Prioridade? Média, talvez até Baixa para este sprint específico.
A severidade não muda. A corrupção de dados ainda é Crítica. Mas a decisão de negócio de agendá-lo depois de um bug Maior no fluxo de checkout voltado ao usuário é completamente racional.
Baixa severidade, alta prioridade. Sua empresa acabou de lançar um produto com co-branding com um parceiro importante. Na homepage, o nome do parceiro está escrito incorretamente. Uma letra trocada.Severidade? Trivial. Nenhum usuário está bloqueado. Nenhum dado está em risco. A aplicação funciona perfeitamente.
Prioridade? Crítica para este release. Jurídico, parcerias e marketing se importam com isso antes do product manager terminar o café da manhã. Vai para a fila de hotfix na frente de um bug Maior num fluxo secundário.
Esse é o caso que pega os QAs juniores com mais frequência. Eles veem "severidade Trivial" e assumem baixa prioridade, depois ficam confusos quando é corrigido em duas horas enquanto o bug Maior fica sem solução.
Exemplos reais dos quatro quadrantes
Cenários concretos para todas as quatro células da matriz.
Alta severidade + Alta prioridade: durante os testes de regressão, você descobre que submeter o formulário de reset de senha com um email válido retorna um erro 500. O email de reset nunca é enviado. Os usuários estão bloqueados sem caminho de recuperação. A aplicação vai ao ar na segunda. Corrija hoje. Alta severidade + Baixa prioridade: a exportação do log de auditoria, usada por oficiais de compliance para relatórios trimestrais, produz um arquivo malformado se o intervalo de datas abrange mais de 18 meses. É genuinamente ruim (risco de integridade de dados), mas a próxima janela de exportação é daqui a 10 semanas. Um workaround existe: rodar duas exportações e mesclar. O time de compliance foi informado. Vai para o backlog do próximo sprint, não deste. Baixa severidade + Alta prioridade: três semanas antes do lançamento público do app, você nota que a meta tag de título da landing page exibe "Untitled Document", um placeholder de template que nunca foi atualizado. Zero impacto funcional. Mas vai aparecer nos resultados do Google e nas pré-visualizações de redes sociais a partir do dia do lançamento. SEO, marketing e o CEO se importam. É corrigido esta tarde. Baixa severidade + Baixa prioridade: o tooltip no painel de filtro avançado diz "Clique para abrr" em vez de "abrir". Está lá há seis meses. Vai ser corrigido numa revisão de UI no próximo trimestre. Nada aqui é urgente.Quem define o quê, e por que importa
A divisão de responsabilidade vale deixar clara.
QA define severidade. Você observou o bug, testou o impacto, sabe o que o sistema deveria fazer. Você está na melhor posição para julgar quão tecnicamente quebrado algo está. Assuma essa decisão. Se um desenvolvedor questionar seu label de severidade, esteja preparado para explicar seu raciocínio. Por exemplo: "Marquei como Crítico porque resulta em perda de dados no cenário afetado, o que pelas nossas definições o coloca nessa categoria."
Produto ou gestão define prioridade. Eles têm contexto que você não tem: quais clientes são afetados, quais compromissos existem, qual é a pressão competitiva, qual é a capacidade do sprint. Respeite que essa é a decisão deles.
Onde as coisas dão errado: QAs que colocam Baixa severidade em tudo para evitar conflito, ou que assumem que tudo que encontraram é Crítico. Os dois padrões corroem a confiança. Severidade precisa é parte do seu output profissional, leve a sério.
Como argumentar por prioridade quando alguém discorda
Você registrou um bug Maior num fluxo principal. O PM responde: "Vemos isso no próximo sprint." Você acha que precisa ir nesta semana.
A forma de defender isso: enquadre em impacto para o usuário e para o negócio, não em orgulho técnico.
Argumento fraco: "Mas este é um bug Maior, tem que ser corrigido agora."
Argumento mais forte: "Isso quebra o fluxo de exportação para qualquer usuário com mais de 500 itens. Com base nos nossos dados de usuário, são aproximadamente 30% das contas ativas. Se publicarmos sexta sem corrigir, vamos receber tickets de suporte. Prefiro sinalizar agora do que lidar com isso pós-release."
Dê ao PM algo para avaliar. Eles estão fazendo uma compensação de risco. Seu trabalho é colocar as informações certas na mesa, não tomar a decisão final. Se eles ouvirem o caso de negócio e ainda decidirem adiar, é uma decisão legítima de produto. Documente que o bug era conhecido e foi triado, registre, e siga em frente.
A escala de cinco níveis versus a de quatro
Alguns times usam cinco níveis de severidade: Crítico, Alto, Médio, Baixo, Trivial. Outros usam quatro (Crítico, Maior, Menor, Trivial). Alguns usam três (Alto, Médio, Baixo).
A escala que você usa importa menos do que a aplicação consistente dentro do seu time. O problema com escalas maiores não é o número de níveis. É que os times acabam debatendo se algo é Alto ou Médio em vez de triar bugs. Se seu time passa 20 minutos discutindo se um bug é Menor ou Trivial, a escala tem mais granularidade do que seu processo consegue suportar.
Para a maioria dos times, quatro níveis funcionam bem. Cinco é adequado se você tem uma organização grande de QA onde a severidade alimenta timers automáticos de SLA. Por exemplo: bugs Críticos devem ser reconhecidos em 2 horas, Altos em 24 horas. Três níveis funcionam em times early-stage de movimentação rápida onde nuance é um luxo.
Escolha uma escala, documente o que cada nível significa com exemplos concretos, e aplique de forma consistente. Consistência importa mais do que precisão.
Como escrever severidade num bug report que não gera debate
O motivo pelo qual a severidade é contestada em reuniões de triagem é quase sempre o mesmo: o label de severidade está lá, mas o raciocínio não está.
"Severidade: Crítico" convida um debate. "Severidade: Crítico: clicar em Enviar descarta silenciosamente o formulário sem nenhum feedback; o usuário acredita que a ação foi bem-sucedida, mas nada é salvo" não convida.
Escreva a severidade como um veredicto curto com evidências. Uma ou duas frases. Declare o impacto, declare por que se encaixa naquela categoria.
O padrão: [Nível de severidade]: [o que o sistema faz de errado] [quem é afetado e como] [por que esta categoria e não uma menor].
Aplicado:
Ruim: Severidade: Maior
Melhor: Severidade: Maior. O fluxo de reset de senha falha para todos os usuários tentando redefinir via browser mobile. Os usuários estão bloqueados na recuperação da conta no mobile; o desktop ainda funciona, que é o workaround.
Essa formulação faz três coisas: justifica o label com o impacto, define o escopo de quem é afetado, e reconhece por que é Maior e não Crítico. Um workaround existe, e isso importa. Qualquer pessoa lendo o ticket entende a decisão de severidade sem precisar te perguntar.
Como aplicar isso a partir de segunda
Quando você registrar seu próximo bug, desacelere nos campos de severidade e prioridade em vez de clicar na primeira opção que parecer certa.
Pergunte a si mesmo: o que realmente quebra aqui, e para quem? Se um usuário encontrar esse bug, consegue completar seu objetivo de outra forma? Afeta todos os usuários ou um segmento específico? Corrompe dados ou apenas incomoda alguém?
Essa resposta é sua severidade. Escreva uma justificativa de uma frase ao lado do label.
Depois olhe o backlog de tickets. O que vai neste sprint? Quem é afetado por este bug em relação ao resto dos bugs aguardando? Esboce uma sugestão de prioridade num comentário, não como exigência, mas como input. Por exemplo: "Dado que isso afeta o fluxo principal de pagamento e a publicação é sexta, eu sugeriria tornar isso prioridade do sprint."
Com o tempo, essa prática faz algo visível: suas decisões de triagem param de ser revertidas. Os PMs param de sobrescrever seus labels. Os desenvolvedores param de questionar seus chamados Críticos. Não é sorte. É porque você separou dois conceitos que a maioria dos QAs juniores colapsa em um, e começou a comunicar a distinção com clareza.
→ Veja também: A Anatomia de um Bug Report que os Desenvolvedores Realmente Corrigem | Como Escrever um Caso de Teste: Formato, Exemplos e Erros Comuns
