Testes exploratórios: quando o script não encontra o bug estranho

A resposta curta: os testes exploratórios existem para encontrar os defeitos que sua suíte automatizada nunca vai procurar, porque um script só verifica o que seu autor já imaginou. Explorar é projetar o teste, executá-lo e aprender com ele ao mesmo tempo, com um humano decidindo o próximo passo conforme o que acabou de ver. Não é clicar ao acaso: é uma disciplina com carta de missão, tempo delimitado e evidência.

Há uma confusão que custa dinheiro. Muita gente acredita que "automatizamos tudo" equivale a "testamos tudo". Não. A automação é excelente para repetir o conhecido e proteger você de regressões. Mas um caso automatizado nasce de uma hipótese que você já tinha. O bug que derruba a produção numa sexta costuma viver justamente fora dessa hipótese, no canto que ninguém pensou em escrever.

01 · o ponto cegoPor que o script não vê o bug estranho

Um script faz uma coisa maravilhosa e uma coisa perigosa. A maravilhosa: executa o mesmo caminho mil vezes sem se cansar e grita se algo muda. A perigosa: nunca sai desse caminho. Se o defeito está num estado que ninguém modelou, o script passa ao lado sem vê-lo, no verde, dando a você uma falsa sensação de cobertura.

O padrão ISO/IEC/IEEE 29119 reconhece isso de forma explícita: o testing baseado em scripts e o testing exploratório são abordagens complementares, não rivais. Uma documenta e repete; a outra descobre. Renunciar à segunda porque você tem a primeira é como vistoriar uma casa apenas pelos corredores que você já varreu.

Um caso automatizado só pode falhar pela razão que seu autor já imaginou.

O testing exploratório ataca esse ponto cego com uma ideia simples: o melhor detector de esquisitices que existe ainda é uma pessoa com critério observando o sistema ao vivo. Quando você vê uma piscada estranha, um total que não fecha por um centavo ou um botão que responde tarde, sua cabeça formula uma hipótese nova na hora e você a testa. Esse ciclo de aprender-enquanto-testa é o que nenhum script fixo pode fazer por você.

02 · a disciplinaNão é clicar ao acaso: cartas, tempo e sessões

Aqui está o mal-entendido que precisa ser enterrado. Testing exploratório não significa "mexer nas coisas para ver o que acontece". Significa aprendizado, projeto e execução de testes de forma simultânea, guiada por um objetivo. A diferença entre um explorador e alguém que clica ao acaso é a mesma que entre um detetive e um curioso: os dois olham, mas só um segue uma linha de investigação.

A forma madura dessa prática se chama Session-Based Test Management (SBTM), proposta por Jonathan e James Bach no início dos anos 2000 para dar estrutura e prestação de contas sem matar a liberdade de explorar. Três peças a sustentam:

A carta de missão (charter). Antes de tocar em nada, você escreve em uma ou duas frases o que vai explorar e por quê. Por exemplo: "explorar o fluxo de checkout com cupons vencidos para descobrir problemas de cálculo do total". A carta foca sem acorrentar; ela diz onde caçar, não como.

O tempo delimitado (time-boxing). A exploração acontece em sessões ininterruptas de entre 60 e 120 minutos. O limite protege o foco e torna o esforço mensurável. Uma sessão não é "a tarde inteira para ver o que aparece"; é um bloco com início, fim e uma missão concreta.

A bitácula (session report). Durante a sessão você anota o que testou, o que encontrou, quais perguntas surgiram e quanto tempo foi para testar frente a investigar bugs ou preparar o ambiente. Essa bitácula transforma uma atividade que parece improvisada em algo revisável, repetível e apresentável a qualquer um.

03 · o equilíbrioO humano como complemento da automação

A pergunta correta não é "automatizar ou explorar", mas "o que cabe a cada um". A automação cobre o que você já sabe que deve continuar funcionando: regressões, fumaça, caminhos felizes críticos, validações repetitivas. A exploração cobre o que você ainda não sabe: comportamentos emergentes, combinações estranhas de estado, problemas de usabilidade que nenhum assert detecta.

Há algo que a exploração exige e que convém nomear: um oráculo, isto é, um critério para decidir se o que você vê está certo ou errado. Num caso automatizado o oráculo está congelado no código. Na exploração o oráculo vive na cabeça do tester, alimentado pela especificação, pela coerência interna do produto e pela experiência. Por isso essa disciplina depende tanto do critério de quem a executa.

A qualidade, entendida como a ISO/IEC 25010 a define em atributos como funcionalidade, usabilidade e confiabilidade, não se esgota em "os asserts passam". Um total que fecha mas um fluxo que confunde o usuário é um produto que passa nos testes e falha com a pessoa. Essa classe de defeito quase sempre é encontrada por alguém explorando, não por um script.

Automatize o que você já entende; explore para entender o que você ainda não entende.

Na prática, uma equipe saudável faz as duas coisas e as conecta. Quando uma sessão exploratória descobre um bug estranho e valioso, esse achado depois vira um caso automatizado que vigia aquele canto para sempre. É assim que a exploração alimenta a automação: o humano descobre o território novo, e o script o defende uma vez conhecido.

A conclusão é direta. Se sua estratégia de qualidade só tem scripts, você está protegido contra os erros que já imaginou e cego diante dos que não imaginou. Adicione exploração governada, com cartas, tempo delimitado e bitáculas, e você dá ao seu produto a única coisa que nenhuma máquina lhe dá ainda: uma mente curiosa caçando o problema que ninguém havia pensado.