QA

QA

Teste de software com objetivo declarado. O entregável de QA não é "testei e funciona": é evidência do que foi coberto, do que ficou de fora, e bugs descritos de forma que a primeira tentativa de reprodução bata.

Método

1. Defina o escopo antes de testar. O que entra (features, telas, endpoints, fluxos), o que fica de fora e por quê. Liste os riscos em ordem: o que quebra o negócio se quebrar? Autenticação, pagamento, perda de dados, migração — primeiro. Cosmético — por último. Se a tarefa não delimita, proponha o escopo no relatório antes de começar.
2. Escreva os casos a partir do comportamento, não da implementação. Um caso: nome ("Login recusa senha incorreta"), pré-condição, passos numerados, resultado esperado verificável. "Funciona bem" não é resultado esperado; "mostra 'Senha incorreta', não revela se o e-mail existe, não trava o formulário" é. Use references/template-caso-de-teste.md para cada caso. Cubra por feature: caminho feliz, cada regra de validação, cada estado de erro, autorização (usuário A não vê dados do usuário B), limite (0, 1, muitos), e o que acontece com conexão lenta ou interrompida.
3. Rode os casos e registre evidência. Resultado real, ambiente (build, navegador, conta, dados), data. Passou com ressalva é falha com nota — não "passou". Caso não executável hoje entra na lista de bloqueados com o motivo.
4. Teste exploratório com charter. Sessão de 60–90 minutos com destino declarado: "Explorar o fluxo de checkout com cupom expirado, buscando cobrança incorreta". Durante a sessão, anote: o que testou, o que observou, bugs, perguntas. Charter dá direção; a sessão segue o interesse quando ele serve ao destino. Um charter por sessão; ao fim, 5 minutos de relatório antes de a memória esfriar.
5. Relate bug que reproduz na primeira tentativa. Cada campo importa: título com comportamento observado, passos numerados partindo do estado mais simples possível, resultado esperado, resultado real, evidência (screenshot, vídeo, log), severidade e ambiente. Antes de relar, reproduza mais uma vez do zero seguindo só os seus passos — se você precisou de um passo que não escreveu, o relato está incompleto. Use references/template-relato-de-bug.md.
6. Severidade e prioridade são coisas diferentes. Severidade é o dano técnico (bloqueia tudo / funcionalidade principal com contorno / menor / cosmético); prioridade é a pressão de negócio para consertar. Crash de upload em prod pode ser severidade alta e prioridade média se há fluxo alternativo. Declare as duas e o motivo.
7. Regressão antes de encerrar. Da suíte, rode: casos que tocam o que a mudança altera, casos que tocam o que a mudança toca por dependência, e os casos que já quebraram antes nessa área. Bugs corrigidos voltam; teste de bug corrigido é candidato permanente à regressão.
8. Feche com veredito, não com lista. O relatório responde: pode sair? Quais os riscos conhecidos do que ficou sem teste? Quais os bugs abertos por severidade? Evidência resumida, não diário de bordo.

Como explorar bem

• Varie uma coisa por vez: dado inválido em cada campo, ação repetida duas vezes, dois usuários no mesmo recurso, rede caindo no meio de uma ação, timeout, voltar com o botão do navegador no meio do fluxo, sessão expirada em tela aberta.
• Fronteiras numéricas: o mínimo, o mínimo menos 1, o máximo, o máximo mais 1, zero, negativo, string enorme, emoji, acento, SQL no campo de texto.
• Estado residual: recarregue no meio de um fluxo, feche o modal e reabra, duplique a aba, volte depois de um dia.
• Não confunda certeza com cobertura: "não achei bug" vale só para o que você efetivamente exercitou e registrou.

Regras

• Nunca teste só o caminho feliz e declare cobertura.
• Nunca relate bug sem reproduzir seguindo exatamente os passos escritos.
• Nunca marque "passou" o que não executou; bloqueado é estado honesto.
• Nunca edite o código para "consertar" durante a sessão de teste: bug vai para o relato; consertar é tarefa de dev, separada.
• Não relar opinião de design como bug ("o botão devia ser azul"): é observação, vai em seção própria.
• Não abra dez bugs para uma mesma causa-raiz: um relato, lista de sintomas.
• Dados de teste: nunca use conta, dado ou credencial real de cliente.

Recuse

• Assinar "testado e aprovado" sem lista do que ficou de fora.
• Cobrir toda a aplicação num plano: proposta de escopo com risco justificado vence lista infinita.
• Automação sem antes ter o caso manual estável: primeiro o comportamento conhecido, depois o script.
• Bug sem passos de reprodução ("o sistema está estranho"): investigue ou pergunte, mas não relate no vazio.

Modelos

• references/template-caso-de-teste.md — para cada caso do plano.
• references/template-relato-de-bug.md — para cada defeito encontrado.