Módulo 4: Teste exploratório

A forma mais usada de organizar isso se chama teste baseado em sessões. Uma sessão tem quatro partes:

• Carta (charter): uma frase dizendo o que você vai investigar e com que olhar. É o contrato da sessão.
• Tempo marcado: 45, 60 ou 90 minutos, sem interrupção. Tempo demais cansa e vira clique automático; tempo de menos não deixa você entrar no assunto.
• Anotação: o que você fez, o que viu de estranho, o que ficou de fora, as perguntas que surgiram.
• Fechamento (debrief): cinco minutos com alguém do time contando o que achou e o que merece uma próxima sessão.

O formato da carta que funciona bem:

Explorar   <área ou funcionalidade>
com        <recursos, dados, ferramentas>
para       <que tipo de informação ou risco>

Explorar  o cupom de desconto no carrinho
com       contas nova e antiga, cupom expirado, cupom já usado,
          e o painel de rede do navegador aberto
para      descobrir se dá pra burlar a regra de "um cupom por pedido"
          ou aplicar desconto abaixo do valor mínimo

Tempo: 60 min          Ambiente: homolog, v2.14

Vinte minutos de sessão e acabaram as ideias, acontece com todo mundo. Heurística é uma lista de provocações que devolve o rumo.

Os "passeios" (tours)

• Passeio do dinheiro: siga tudo que envolve valor: preço, desconto, frete, imposto, estorno. É onde o defeito custa caro.
• Passeio do CRUD: para cada entidade: criar, ler, atualizar, apagar. E depois: apagar e tentar ler de novo; atualizar duas vezes seguidas.
• Passeio do turista: visite as telas que ninguém visita: erro 404, página de termos, recuperação de senha, estado vazio ("você não tem pedidos").
• Passeio do sabotador: desligue a internet no meio, aperte o botão duas vezes, volte pelo botão do navegador, atualize a página no meio do fluxo.
• Passeio do supermercado: encha o carrinho: 99 itens, nome com 300 caracteres, upload de arquivo gigante.

O pente SFDIPOT

Uma varredura por sete ângulos, pra não ficar só no fluxo feliz:

Letra	Ângulo	Pergunta que ele provoca
S	Estrutura	de que partes isso é feito? o que existe além da tela?
F	Função	o que isso faz? e o que faz quando dá errado?
D	Dados	que dados entram e saem? vazio, enorme, estranho, duplicado?
I	Interfaces	com que outros sistemas conversa? e se um cair?
P	Plataforma	navegador, celular, sistema, resolução, conexão ruim
O	Operações	como as pessoas realmente usam isso no dia a dia?
T	Tempo	ordem dos eventos, simultaneidade, timeout, fuso, data virando

Dica: T de tempo é o ângulo mais esquecido e o que rende mais defeito: dois cliques rápidos, duas abas abertas, sessão expirando no meio do pagamento.

Oráculo é o que te permite dizer "isso aí está errado". Sem oráculo você está só passeando pelo sistema. Você tem mais oráculos do que imagina:

• Especificação: a história, o contrato da API, o desenho no Figma.
• Consistência interna: a mesma data aparece em dois formatos em duas telas; o total da lista não bate com o total do resumo.
• Consistência com o passado: antes funcionava assim, e ninguém pediu pra mudar.
• Comparável: o concorrente, ou outra parte do mesmo produto, faz de um jeito claramente melhor.
• Propósito: atende ao que a pessoa realmente precisa fazer ali?
• Os dados: o que o banco diz. Este é o oráculo mais forte que existe, e é o que as trilhas de SQL e de API te ensinam a usar: a tela mostra "pedido confirmado", mas a linha em pedidos ficou com valor_total = 0.

Quando você não tem oráculo pra alguma coisa, isso em si é um achado da sessão: "ninguém sabe dizer qual é o comportamento correto aqui" é uma informação que o time precisa ouvir.

Use exploratório quando…	Use roteiro / automação quando…
a funcionalidade é nova e você ainda está entendendo	o fluxo é estável e vai ser conferido muitas vezes
a especificação é vaga ou não existe	o resultado é objetivo e a regra é clara
o risco é alto e você quer olhar com calma	é regressão: precisa rodar a cada entrega
tem pouco tempo e você precisa cobrir muita área	precisa de prova auditável e repetível
já corrigiram um bug e você desconfia da vizinhança	vai rodar no CI e reprovar o build

O fluxo saudável costuma ser: explorar primeiro pra descobrir o que importa, roteirizar depois os casos que valem repetir, e automatizar os que vão rodar sempre. Exploratório alimenta a automação, não compete com ela.

Olhar de QA

Quando terminar uma sessão, o entregável não é "testei". É um resumo curto: o que cobri, o que achei, o que não deu tempo, e o que me preocupa. Esse último item é o mais valioso e o que quase ninguém escreve: é ele que transforma você de executor em alguém que o time consulta antes de decidir se sobe pra produção.