Testes Exploratórios: A Habilidade que a IA Não Consegue Substituir

Testes com script verificam o comportamento que alguém pensou em especificar. O exploratory testing encontra o bug onde selecionar 200 itens do catálogo, navegar para outra tela e voltar para selecionar novamente submete alterações para 400 itens. Ninguém especificou o que acontece com o estado de seleção oculto.

O que é exploratory testing de verdade

A definição mais sólida vem de James Bach e Michael Bolton: exploratory testing é aprendizado, design de testes e execução simultâneos. Você não faz essas coisas em sequência. Faz tudo ao mesmo tempo, em tempo real.

Com testes com script, alguém escreve o caso de teste primeiro e um tester executa depois, frequentemente dias ou semanas depois. A pessoa que projeta o teste e a que executa podem nem ser a mesma. No exploratory testing não há essa lacuna. O que você descobre nos primeiros cinco minutos molda onde você vai nos cinco seguintes. O teste evolui conforme você aprende.

Isso não é uma forma inferior de teste. É um modo cognitivo completamente diferente. Testes com script se destacam em verificação: confirmar que um comportamento conhecido ainda se mantém. Exploratory testing se destaca em descoberta: encontrar comportamentos que ninguém pensou em escrever um script.

Exemplo concreto: o time lança uma feature de edição em massa para um catálogo de produtos. Os testes com script cobrem selecionar itens, aplicar uma mudança, confirmar o save. Durante uma sessão exploratória, você seleciona 200 itens, começa a editar, então navega para outra tela antes de salvar. Quando volta e seleciona itens de novo, a seleção anterior ainda está ativa em estado oculto. Submeter o formulário agora aplica alterações a 400 itens. Ninguém especificou esse cenário. Nenhum script verificou isso. Sua curiosidade encontrou.

Por que scripted e exploratory testing resolvem problemas diferentes

Se você manda o mesmo tester executar um script de regressão de 50 passos todo sprint, ele para de ver a aplicação. Está lendo uma lista e clicando em caixas. A carga cognitiva cai a quase zero, o que significa o mesmo para a detecção de bugs, a menos que o bug coincida exatamente com um passo do script.

O exploratory testing exige atenção total. Você está formando hipóteses, tentando refutá-las e reagindo ao que encontra. "Esse dropdown carrega devagar. O que acontece se eu submeter o formulário antes de terminar de popular?" Esse pensamento não aparece em nenhum documento de caso de teste. Aparece porque você está pensando enquanto testa.

A distinção importa para como você planeja o trabalho de testes. Quando você herda uma feature estável com boa cobertura de automação, a regressão com script é a ferramenta certa. Quando está olhando para uma feature recém-construída, uma integração com terceiros, ou qualquer coisa que toca várias partes do sistema de formas não óbvias, exploratory testing é a escolha certa. Ele encontra o que o scripted testing perde.

Nenhuma abordagem é superior. Escolher a certa, ou a combinação certa, é a habilidade.

Session-Based Test Management: estrutura sem rigidez

A exploração sem estrutura é onde a crítica de "clicar aleatoriamente" tem alguma verdade. Se você abre uma aplicação sem objetivo, sem limite de tempo e sem registro do que fez, vai cobrir o mesmo terreno repetidamente e deixar grandes áreas de fora. Não vai ter nada útil para mostrar no final.

O Session-Based Test Management (SBTM), desenvolvido por Jonathan e James Bach, resolve isso sem transformar a exploração em scripted testing.

A unidade central é uma sessão de testes: um bloco de teste ininterrupto, geralmente de 60 a 90 minutos, com três componentes.

O charter define a missão. Não é um caso de teste, é uma pergunta focada. "Explorar a feature de exportação de faturas com atenção a casos extremos em pedidos com múltiplas moedas." Isso é um charter. Diz onde começar e o que observar, mas não dita o caminho. Você pode e deve seguir threads interessantes conforme aparecem.

O time box mantém as sessões honestas. 90 minutos de exploração focada é significativamente mais produtivo que quatro horas à deriva. A restrição força priorização. Se você tem apenas 90 minutos, vai primeiro para as áreas de maior risco.

O debrief é onde o valor da sessão é capturado. Após a sessão, você gasta 10–15 minutos resumindo o que cobriu, o que encontrou, o que não chegou a fazer e quais questões ficaram abertas. Esse resultado é o que torna o exploratory testing visível para o restante do time.

Na prática, um charter pode ser: "Explorar o checkout quando usuários trocam de método de pagamento durante a sessão, com foco em tratamento de erros e gerenciamento de estado." Você coloca um time box de 60 minutos, testa com intenção e faz o debrief. As notas resultantes são sua entrega: não um relatório de passou/falhou, mas um mapa do que você aprendeu.

Heurísticas que guiam onde procurar

Testers exploratórios experientes não vagam. Eles seguem heurísticas: atalhos mentais que apontam para áreas com probabilidade maior de conter problemas.

A heurística SFDPOT (desenvolvida por James Bach) oferece seis lentes: Estrutura, Função, Dados, Plataforma, Operações e Tempo. Aplicadas a uma nova feature, você pergunta: a estrutura do modelo de dados cria vulnerabilidades? O que acontece nas bordas das entradas aceitas? O comportamento muda em plataformas ou navegadores diferentes? O que acontece quando isso roda sob carga, ou quando um processo dependente de tempo é interrompido?

Você não aplica as seis a cada sessão. Usa como prompts quando sente que está ficando sem ideias.

Personas de usuário funcionam junto com heurísticas. Um usuário avançado que memorizou atalhos de teclado interage com o produto de forma muito diferente de quem abre pela primeira vez. Um usuário com conexão ruim de rede acerta casos extremos diferentes de quem está na fibra. Incorporar uma persona específica mantém a exploração coerente e ajuda a descobrir modos de falha específicos daquela persona.

Áreas de risco são o terceiro guia. Código novo tem mais bugs que código antigo. Integrações entre sistemas têm mais bugs do que qualquer sistema individualmente. Features com estado complexo (wizards de múltiplos passos, carrinhos de compra, formulários com lógica condicional) têm mais bugs do que telas CRUD simples. Direcione sua exploração para lá primeiro.

Técnicas de tour: três que dão retorno imediato

Cem Kaner introduziu a ideia de aplicar metáforas de turismo ao exploratory testing, depois expandida por Michael Kelly. Três tours valem ser conhecidos de cor.

O feature tour é a cobertura sistemática das capacidades de uma feature, mas abordada com curiosidade em vez de checklist. Você está visitando cada sala do prédio (cada função principal, cada ponto de interação) não para confirmar que funciona, mas para entender o suficiente para saber onde sondar mais fundo. Em um novo módulo de relatórios, isso significa gerar cada tipo de relatório, aplicar cada filtro, exportar em cada formato disponível. Não para verificar, mas para mapear o território.

O complexity tour caça interações entre features. Você procura lugares onde dois sistemas se tocam de formas que podem não ter sido projetadas juntas. Um formulário de pagamento que também aplica códigos de desconto é mais complexo do que cada um isolado. Uma ação no painel admin que dispara um email de notificação é mais complexa do que cada uma isolada. Você testa a costura. Em uma ferramenta de gestão de projetos, isso pode significar: criar uma tarefa, atribuí-la a um usuário, e então desativar esse usuário imediatamente. O que acontece com a tarefa? O campo de usuário atribuído lida com uma referência agora inválida de forma adequada?

O interruption tour testa resiliência. Conexões lentas. Navegação durante um processo. Botão voltar do navegador durante um envio de formulário. Fechar uma aba durante upload de arquivo. Timeout de sessão no meio do checkout. Aplicações modernas lidam bem com o happy path. O interruption tour procura tudo que acontece quando o usuário não se comporta como o happy path assume. Um wizard de onboarding de três passos pode funcionar perfeitamente quando completado normalmente. O estado se perde se o usuário clicar no botão voltar do navegador entre os passos dois e três.

Documentando achados sem matar o fluxo

A pior coisa que você pode fazer durante uma sessão exploratória é parar para escrever um bug report formal. Você quebra o modelo mental, perde o fio do raciocínio e passa o restante da sessão em um modo cognitivo diferente.

A solução é separação: capture durante a sessão, formalize depois.

Durante a sessão, você quer notas rápidas e descartáveis. Post-its na mesa física. Uma nota de rascunho no VS Code ou Notepad. Anotações breves enquanto faz screenshots. O objetivo é informação suficiente para reconstruir o que você encontrou, não um relatório polido.

Screenshots devem ser anotados imediatamente com uma seta de destaque antes de continuar. A anotação diz em dois dias por que você tirou aquele screenshot. Sem ela, um screenshot de um filtro de dropdown quebrado é apenas um screenshot.

Loom (ou qualquer gravador de tela) vale usar para qualquer coisa que envolva uma sequência de passos. Grave os passos, narre o que você está fazendo e por que é inesperado, e salve o link nas suas notas de rascunho. Um Loom de 90 segundos de uma reprodução vale mais do que um bug report de 400 palavras, e leva menos tempo para criar.

Após a sessão, revise as notas de rascunho e decida quais achados merecem bug reports formais. A maioria das sessões exploratórias produz uma mistura de bugs confirmados, perguntas para o desenvolvedor, observações comportamentais e coisas para acompanhar. O relatório formal vem depois da sessão, não durante.

Por que IA não consegue fazer isso

O argumento de que IA vai substituir o exploratory testing geralmente diz: "IA consegue gerar casos de teste, aprender com bugs passados e explorar a aplicação de forma inteligente." Parte disso já acontece. Ferramentas com IA rastreiam aplicações, geram scripts de teste e sinalizam regressões visuais. Isso é útil.

O que não é exploratory testing.

O exploratory testing depende de intuição de domínio: conhecimento sobre como usuários realmente se comportam no contexto específico de um produto específico. Um tester que passou três meses em uma plataforma de e-commerce sabe que usuários com listas de desejos grandes se comportam diferente no checkout. Que o campo de código promocional atrai tentativas de injeção. Que a validação de endereço quebra de formas específicas para endereços fora dos EUA que desenvolvedores centrados nos EUA consistentemente ignoram. Isso não está em nenhum dataset de treinamento de forma utilizável. É contexto acumulado.

De forma mais fundamental, o exploratory testing depende de curiosidade movida por significado. Quando você vê um dropdown lento, se pergunta o que acontece durante aquela janela de lentidão. Você entende o que um usuário está tentando fazer e por que a latência cria um risco. Uma IA vê uma métrica de performance. Você vê um modo de falha.

Ferramentas de IA são excelentes para executar caminhos conhecidos em escala, identificar regressões em relação a um baseline e detectar anomalias em logs e métricas. Um modelo treinado em casos de teste passados não consegue responder "sobre o que devo ser curioso aqui?" para um sistema que nunca encontrou em um contexto que nunca viu.

O trabalho do tester exploratório é exatamente encontrar o que ninguém pensou em especificar. Isso exige fazer perguntas que ninguém pensou em fazer, o que exige entender o domínio, os usuários e o produto profundamente o suficiente para saber quais perguntas importam. Isso não é automação. É expertise.

Como aplicar isso na segunda-feira de manhã

Você não precisa de um programa formal de SBTM para começar. Aqui está um ponto de partida prático que cabe em um sprint normal.

Escolha uma feature que foi recentemente alterada ou lançada. Escreva um charter em uma frase: "Explorar [feature] com foco em [área de preocupação]." Passe 60 minutos nisso. Faça notas em um documento de rascunho conforme avança. No final, gaste 10 minutos revisando as notas e registrando os bugs que encontrou.

Essa é uma sessão exploratória. Faça isso consistentemente (uma ou duas por sprint) e você vai começar a encontrar coisas que a suite de automação nunca encontraria.

Ao escrever charters, alterne o foco. Uma sessão em casos extremos de dados. A próxima na interação entre essa feature e uma adjacente. A próxima no que acontece quando o usuário se comporta de forma inesperada. A variedade é o ponto.

Por fim, faça o debrief compartilhando as notas da sessão com o time, mesmo que informalmente. Uma mensagem rápida no Slack constrói visibilidade para um trabalho que de outra forma acontece invisivelmente. Por exemplo: "rodei uma sessão exploratória no fluxo de edição em massa, encontrei dois bugs, percebi que o tratamento de erros para falhas parciais não está claro." Também transforma o exploratory testing em uma prática do time em vez de um hábito individual.

O exploratory testing não é um complemento para uma estratégia de testes "real". É a parte da estratégia que pega o que todo o resto perde. Times que fazem isso consistentemente lançam com menos regressões e encontram mais bugs críticos antes da produção. A habilidade é aprendível, melhorável, e completamente sua.