Severidade vs prioridade: por que um bug crítico pode esperar

A severidade mede quanto dano um defeito causa quando acontece. A prioridade mede quão cedo convém corrigi-lo. São duas perguntas diferentes: uma é respondida pelo sistema (quão grave é a falha técnica), a outra pelo negócio (quão urgente é o reparo). Confundi-las é a razão pela qual tantas equipes corrigem coisas feias mas inofensivas antes de coisas discretas mas perigosas.

A cena típica é esta. Um tester encontra um botão que aparece mal em uma tela que quase ninguém visita: é horrível, mas ninguém trava por causa dele. Ao mesmo tempo há um cálculo de impostos que erra por centavos no checkout, algo que quase não se percebe, mas que custa dinheiro real à empresa todos os dias. O primeiro grita mais alto. O segundo faz mais estrago. Decidir qual vem primeiro é, exatamente, o trabalho de separar severidade de prioridade.

01 · as duas perguntasSeveridade é quanto dói, prioridade é quando você corrige

O vocabulário padrão de testes as define separadamente de propósito. A severidade é o grau de impacto que um defeito tem sobre o desenvolvimento ou a operação de um componente ou sistema [1]. É uma propriedade quase objetiva da falha: derruba a aplicação, corrompe dados, ou apenas desalinha um ícone? A prioridade, por sua vez, é o nível de importância de negócio atribuído a resolvê-lo: quão acima na fila de correções você o coloca [1].

A distinção importa porque as duas não se movem juntas. Um defeito pode ser muito severo e de baixa prioridade, ou pouco severo e de altíssima prioridade. Essa independência é justamente o que a torna útil: obriga você a pensar o impacto técnico e a urgência comercial como dois eixos, não como um só.

A severidade é definida pelo sistema. A prioridade é definida pelo negócio. Quando você as mistura, corrige por volume de reclamação, não por dano real.

Quem atribui cada uma também difere. A severidade é proposta por quem entende o comportamento técnico do defeito: o tester ou o desenvolvedor que o reproduz. A prioridade é decidida por quem entende o custo de deixá-lo solto: o dono do produto, o líder ou o próprio negócio. Quando uma única pessoa define as duas "no olho", quase sempre colapsa ambas em um único número borrado, e é aí que começa a bagunça.

02 · os quatro quadrantesPor que um bug crítico às vezes pode esperar

Como severidade e prioridade são eixos independentes, elas se cruzam em quatro combinações. Cada uma pede uma decisão diferente, e os dois cantos incômodos (alta-baixa e baixa-alta) são os que mais se interpretam mal.

Alta severidade, alta prioridade. O caso fácil. O app cai no fluxo de pagamento para todos os usuários. Dói muito e precisa ser corrigido já. Ninguém discute este quadrante.

Alta severidade, baixa prioridade. Aqui vive o "bug crítico que pode esperar". Imagine uma falha que corrompe os dados, mas só dispara em uma versão do sistema operacional usada por 0,1 % dos seus usuários, em uma função que será lançada no mês que vem. Tecnicamente é grave. Comercialmente, hoje, não urge: você pode agendá-lo sem pânico. Severidade alta, prioridade baixa.

Baixa severidade, alta prioridade. O espelho. Um erro de ortografia no nome da sua empresa na página inicial, ou o logo de um cliente chave mal colocado bem antes de uma demo. O sistema funciona perfeitamente: severidade mínima. Mas a vergonha ou o risco comercial são enormes, então se corrige na próxima hora. Prioridade máxima.

Baixa severidade, baixa prioridade. O fundo da fila. Uma margem de dois pixels em uma tela interna que três pessoas veem. Registra-se, agenda-se para algum dia, e às vezes nunca se toca. E está tudo bem que seja assim.

03 · como decidirOrdenar com dados, não com quem grita mais alto

O problema real não é entender a diferença na teoria, é não aplicá-la sob pressão. Quando o relato de um cliente barulhento chega por um canal direto, tende a furar a fila, mesmo que seu defeito seja leve. E quando uma falha grave vive em um canto que ninguém relata, afunda no backlog, mesmo que um dia exploda. Decidir "por quem grita mais alto" é exatamente o viés que a matriz existe para corrigir.

Para ordenar a prioridade com dados, em vez de com volume de reclamação, três perguntas concretas ajudam quase sempre.

Quantas pessoas afeta? Uma falha que atinge todos os usuários pesa mais do que uma que atinge um caso muito raro, mesmo que a segunda seja tecnicamente mais severa. O alcance empurra a prioridade para cima.

Existe forma de contorná-lo? Se existe um contorno simples (outro caminho na interface, um passo manual), a urgência cai, mesmo que a severidade fique intacta. Um defeito sem escapatória escala; um com saída de emergência pode esperar sua vez.

Quanto custa deixá-lo solto mais um dia? Dinheiro perdido, risco jurídico, reputação, uma quebra de contrato. Esse custo diário, não a feiura do sintoma, é o que deve empurrar a prioridade. Um defeito que sangra dinheiro a cada hora sobe mesmo que quase não se veja.

Um quadro maduro não pergunta "qual é o mais feio?". Pergunta "o que nos custa mais deixar solto hoje?".

Na Qirava vemos o mesmo padrão repetidas vezes: as equipes que separam bem esses dois eixos discutem menos e entregam com a consciência tranquila, porque sua fila de correções é auditável. Qualquer um pode ver por que um defeito vem antes de outro, e essa razão não é "alguém com voz forte pediu", mas um dado: alcance, contorno disponível, custo por dia. A severidade se documenta, a prioridade se justifica, e a decisão deixa de ser uma briga de opiniões.

Então, na próxima vez que alguém disser "é crítico, temos que corrigir já", pare e separe as duas perguntas. É crítico porque dói muito, ou porque urge muito? Às vezes são a mesma coisa. Muitas vezes não. E saber quando não são é a diferença entre uma equipe que apaga incêndios pequenos e uma que protege a casa.