Módulo 5: Relatar bug

Campo	Para que serve
Título	a pessoa decide em 3 segundos se é com ela. É o campo mais lido e o mais maltratado.
Ambiente e versão	dev / homolog / produção, versão do sistema, navegador e aparelho. Sem isso, "na minha máquina funciona" é inevitável.
Pré-condições	o estado necessário antes de começar: que tipo de usuário, que dado precisa existir.
Passos	numerados, do zero, sem pular nada que pareça óbvio. Quem lê não estava lá.
Resultado esperado	o que deveria acontecer, e por quê: a regra, a história, a tela de referência.
Resultado obtido	o que aconteceu de fato. Descreva, não interprete.
Evidência	print, vídeo curto, log, resposta da API, a linha do banco. Uma imagem economiza um parágrafo.
Severidade e prioridade	dois campos diferentes, a seção abaixo é inteira sobre isso.

Título: a fórmula que funciona

[onde]  o quê acontece  [quando / em que condição]

Ruim	Bom
Erro no checkout	[Checkout] Frete cobrado em pedido acima de R$ 300, que deveria ser grátis
Não funciona	[Login] Botão "Entrar" não responde no Safari iOS 17
Bug no carrinho urgente!!!	[Carrinho] Cupom continua aplicado após remover itens e ficar abaixo do mínimo de R$ 50

Teste do título: se a pessoa ler só ele e conseguir dizer onde procurar no código, está bom.

São duas perguntas diferentes, feitas por pessoas diferentes. Confundir as duas é o mal-entendido mais comum de quem está começando, e um dos poucos temas que cai em praticamente toda entrevista de QA.

• Severidade: o tamanho do estrago quando o defeito acontece. É uma avaliação técnica, e normalmente quem reporta é quem define.
• Prioridade: a urgência de corrigir. É uma decisão de negócio: depende de quanta gente é afetada, do impacto financeiro, de contrato, de imagem, do que mais está na fila.

Por serem independentes, existem os quatro cruzamentos, e os dois cruzamentos "estranhos" é que provam que os campos são mesmo diferentes:

	Prioridade alta (P1)	Prioridade baixa (P4)
Severidade crítica	Checkout derruba o sistema pra todo mundo. Óbvio: pare tudo.	Sistema quebra ao gerar relatório num formato que dois clientes usam, uma vez por ano. Estrago enorme, mas quase ninguém é afetado: pode esperar.
Severidade baixa	Nome da empresa escrito errado na página inicial, no dia do lançamento. Não quebra nada, mas é a primeira coisa que todo mundo vê: corrija agora.	Texto desalinhado por 2 pixels numa tela interna. Óbvio: entra na fila.

Guarde os dois exemplos do meio: o do relatório anual e o do nome errado na home. Eles são a resposta pronta pra pergunta "qual a diferença entre severidade e prioridade?".

O banco que você vai usar nas outras trilhas tem uma tabela defeitos com exatamente os estados que um bug percorre na vida real:

aberto ──→ em_analise ──→ resolvido ──→ fechado
                              │              │
                              └──────────────┴──→ reaberto ──┐
                                                      ▲      │
                                                      └──────┘

• aberto: você reportou, ninguém pegou ainda.
• em_analise: alguém está investigando ou corrigindo.
• resolvido: a correção foi feita. Ainda não acabou: falta você fazer o reteste (Módulo 2).
• fechado: você retestou e confirmou. Só QA fecha.
• reaberto: o reteste falhou, ou o problema voltou depois. É um sinal importante: muitos reabertos indicam correção apressada ou relatório incompleto.

Repare no gancho com o Módulo 3: isso é uma máquina de estados, e as transições proibidas valem teste: dá pra fechar um defeito que nunca foi resolvido? E há uma regra de dados fácil de verificar: todo defeito fechado ou resolvido precisa ter data_fechamento preenchida; todo aberto precisa ter data_fechamento nula. Nas trilhas de SQL e de pytest você escreve exatamente essas verificações, e elas encontram dado inconsistente de verdade.

Os campos da tabela defeitos, e por que cada um existe

Coluna	Para que serve no dia a dia
titulo	a triagem inteira acontece lendo só esta coluna
modulo	permite ver onde os defeitos se agrupam (princípio 4 do Módulo 1)
severidade	tamanho do estrago, técnico
prioridade	urgência, negócio
status	onde o defeito está no ciclo acima
ambiente	dev / homolog / producao: defeito crítico que escapou pra produção é a métrica mais dolorida e mais útil de um time de QA
data_abertura / data_fechamento	a diferença entre as duas é o tempo de correção; a segunda nula significa "ainda aberto"

Quando você chegar na Trilha de SQL, vai reconhecer essa tabela, e as consultas vão fazer sentido de negócio, não só de sintaxe.

"Não consegui reproduzir"

Antes de reportar, tente de novo do zero, em outra conta e, se der, em outra máquina. Se acontece só às vezes, diga isso e diga a frequência real ("3 vezes em 10 tentativas"). Junte tudo que possa ser a diferença: horário, dado usado, se havia outra aba aberta, o log do console. Bug intermitente é bug: o que não pode é você esconder que é intermitente.

"Isso é duplicado"

Procure antes de abrir. Se for o mesmo defeito, acrescente sua informação no relatório existente em vez de abrir outro: outro ambiente, outro caminho de reprodução, mais uma ocorrência. Isso aumenta a prioridade do que já existe, o que é melhor do que dividir a atenção em dois registros.

"Não é bug, é o comportamento esperado"

Acontece, e não tem problema. A resposta profissional não é insistir: é perguntar onde está escrito. Se estiver documentado, ótimo: você aprendeu algo e o relatório fecha. Se ninguém souber dizer, o defeito mudou de lugar: não está no código, está na especificação. Aí o registro certo é "comportamento indefinido: ninguém sabe qual deveria ser", e isso precisa ser decidido por alguém, não silenciado.

Olhar de QA

Escreva o relatório do lado de quem vai corrigir, não contra. Descreva o comportamento, nunca a pessoa; separe fato de hipótese; e entregue de bandeja tudo que economize tempo de investigação. A diferença entre "o checkout está um desastre" e "o checkout soma os dois descontos quando o cliente é VIP" não é só educação: é que a segunda frase pode ser corrigida.