Módulo 1: O que é testar

Três palavras que o mercado usa como sinônimo e que não são. Saber separar muda a forma como você escreve um relatório de bug:

• Erro (error, engano): a ação humana que deu origem ao problema. A pessoa desenvolvedora entendeu que o desconto era de 10% quando era 15%.
• Defeito (defect, bug): a consequência do erro no código. A linha preco * 0.9 está lá, parada, errada, mesmo que ninguém passe por ela.
• Falha (failure): o defeito se manifestando quando o sistema roda. O cliente vê R$ 90 na tela quando deveria ver R$ 85.

Por que importa: você observa falhas e reporta falhas: "o total mostrado é 90, o esperado é 85". Quem investiga acha o defeito. Um relatório que tenta adivinhar o defeito ("acho que a variável do desconto está trocada") e erra faz o time gastar tempo defendendo código em vez de olhar o sintoma. Relate o que você viu.

1. Teste mostra a presença de defeitos, nunca a ausência

Se você rodou 500 casos e todos passaram, você provou que aqueles 500 caminhos funcionam. Nada além disso. Muda o quê: nunca escreva "o sistema está sem bugs" num relatório. Escreva "não encontramos defeitos nos cenários X, Y e Z; não cobrimos W".

2. Teste exaustivo é impossível

Um formulário com 5 campos de 10 valores possíveis cada já dá 100 000 combinações. Some navegadores, permissões e estados do banco e o número perde o sentido. Muda o quê: seu trabalho não é cobrir tudo, é escolher o subconjunto que encontra mais defeito por hora gasta. Isso tem técnica, e está no Módulo 3.

3. Testar cedo custa menos (shift left)

Um requisito ambíguo pego na reunião de refinamento custa uma conversa de cinco minutos. O mesmo problema descoberto em produção custa investigação, correção, nova entrega, cliente irritado, e às vezes dinheiro de verdade. Muda o quê: a pergunta "e se o CEP não existir?" feita antes de alguém programar vale mais do que qualquer bug que você ache depois. Estar na reunião é parte do trabalho de QA.

4. Defeitos andam em bando (agrupamento)

Na prática, poucos módulos concentram a maior parte dos defeitos, geralmente os mais complexos, os mais mexidos, ou os que um time novo acabou de assumir. Muda o quê: achou dois bugs no checkout? Não vá embora testar outra coisa. Fique ali, tem mais. (Na Trilha de SQL você vai medir isso de verdade: contar defeitos por módulo é literalmente um dos exercícios.)

5. Paradoxo do pesticida

Rodar sempre a mesma bateria de testes é como usar sempre o mesmo veneno: mata o que já matava e para de achar coisa nova. Muda o quê: uma suíte de regressão que passa 100% há seis meses talvez não esteja te protegendo: talvez esteja só te tranquilizando. Revise, acrescente casos, e reserve tempo pra teste exploratório (Módulo 4).

6. Teste depende do contexto

Um app de banco, um jogo mobile e um painel interno usado por 3 pessoas não se testam do mesmo jeito nem com o mesmo rigor. Muda o quê: desconfie de receita pronta ("todo projeto precisa de 80% de cobertura"). A pergunta certa é sempre "o que dá errado aqui, e quanto custa?".

7. Ausência de defeitos é uma ilusão

Dá pra entregar um sistema sem nenhum bug conhecido e ainda assim inútil, porque resolve o problema errado. Muda o quê: além de "funciona como especificado?", cabe a pergunta "isso resolve o problema de quem vai usar?". QA que só confere a especificação deixa passar o defeito mais caro de todos.

Duas perguntas diferentes, fáceis de confundir:

A maior parte do teste automatizado é verificação. A validação costuma vir de conversa, de teste exploratório e de olhar quem usa. Um QA que só verifica é substituível por um script; um QA que também valida, não.

O mito é que QA é a última etapa, a bancada no fim da esteira. Num time moderno a atuação é distribuída:

refinamento  →  desenvolvimento  →  pull request  →  homologação  →  produção
     ↑                 ↑                 ↑                ↑              ↑
 perguntar o      combinar o que     ler o diff,      testar o que    monitorar,
 que não está     será testado,      rodar a suíte,   foi entregue,   investigar
 escrito, achar   preparar massa     revisar os       exploratório,   incidente,
 caso esquecido   de teste           testes           cruzar dados    olhar métrica
                                     automatizados    no banco

Repare que boa parte do valor está antes de o software existir. Um caso de teste esquecido que você levanta no refinamento não vira bug nunca.

Olhar de QA

Quando alguém disser "testa aí pra ver se está tudo certo", a resposta profissional não é sair clicando. É perguntar: o que mudou?, o que isso pode ter quebrado que não é óbvio?, quem se machuca se der errado? e quanto tempo eu tenho?. Essas quatro perguntas transformam uma tarefa vaga numa estratégia, e são o que separa quem está começando de quem o time escuta.