Existe uma confusão comum: achar que teste exploratório é "clicar por aí sem rumo". É o oposto. O teste exploratório é uma abordagem em que design, execução e aprendizado acontecem ao mesmo tempo — cada resultado que você observa orienta o próximo passo. É disciplina, não bagunça. E é justamente o tipo de teste que a automação não consegue fazer: usar a cabeça em tempo real.

Scripted vs exploratório

No teste roteirizado (scripted), alguém projeta os casos antes e depois alguém os executa — o pensamento e a ação são separados no tempo. No exploratório, eles são simultâneos:

  SCRIPTED:     pensar  →  escrever caso  →  (depois)  →  executar
                (o teste só faz o que foi previsto)

  EXPLORATÓRIO: pensar + executar + aprender   (em loop, ao mesmo tempo)
                   ▲                    │
                   └──── o que observei guia o próximo passo ────┘

Os dois são complementares. O scripted (e a automação) garante cobertura repetível do esperado; o exploratório encontra o inesperado — o bug que ninguém imaginou ao escrever os casos.

Automação verifica o que você já sabe perguntar. O teste exploratório descobre as perguntas que você ainda não fez.

O problema: como gerenciar algo tão livre?

Se o exploratório não tem roteiro, como planejar, medir e reportar? A resposta é o Session-Based Test Management (SBTM), criado por James e Jonathan Bach. Ele dá estrutura sem matar a liberdade, através de três ideias:

• Charter (carta de missão): uma frase curta que define o foco da sessão — o que explorar e com que objetivo. Ex.: "Explorar o upload de arquivos com foco em formatos e tamanhos inválidos."
• Sessão time-boxed: um bloco ininterrupto e cronometrado (tipicamente 60–90 min) dedicado a um charter.
• Notas e debrief: registro do que foi testado, bugs, dúvidas e ideias — seguido de uma conversa rápida com o time.

Assim o exploratório vira reportável: dá para dizer "rodei 3 sessões sobre o checkout, achei 2 bugs e 4 perguntas de regra" — métrica concreta sobre uma atividade criativa.

Heurísticas: o que guia a investigação

O exploratório não é aleatório porque o testador usa heurísticas — atalhos mentais que apontam onde costuma haver defeito. Duas muito usadas:

SFDPOT (James Bach) — "passear" pelo produto por dimensões:
  Structure   o que o produto É (arquivos, código, hardware)
  Function    o que ele FAZ (recursos, cálculos, tratamento de erro)
  Data        o que ele PROCESSA (entradas, saídas, dados grandes/vazios)
  Platform    de que ele DEPENDE (SO, navegador, dependências)
  Operations  como ele é USADO (perfis de uso, ambientes)
  Time        como o TEMPO afeta (timeout, fuso, concorrência)

RCRCRC (regressão) — onde olhar quando o tempo é curto:
  Recent      o que mudou recentemente
  Core        funções essenciais do produto
  Risk        áreas de maior risco
  Configuration  itens sensíveis a configuração
  Repaired    o que foi corrigido há pouco
  Chronic     o que vive quebrando

Heurísticas transformam "testar à toa" em "testar com hipóteses" — você ataca o sistema por ângulos onde a experiência diz que bugs se escondem.

Onde isso vive na estratégia

Nos quadrantes de Agile Testing, o exploratório é o coração do Q3 (testes que criticam o produto sob a ótica do negócio). Ele não substitui a automação da base da pirâmide — combina com ela: a automação cobre a regressão repetitiva e libera o tempo do humano para a investigação que só o humano faz bem.

Conclusão

Teste exploratório é pensamento crítico aplicado em tempo real, e o session-based testing é o que o torna gerenciável e reportável. Dominar charters, sessões time-boxed e heurísticas como SFDPOT e RCRCRC é o que distingue o QA que "testa a tela" do que investiga o produto — e é onde aparecem os bugs que nenhum roteiro previu.

There is a common misconception: that exploratory testing is "clicking around aimlessly". It's the opposite. Exploratory testing is an approach where design, execution and learning happen at the same time — each result you observe guides the next step. It's discipline, not chaos. And it is precisely the kind of testing that automation can't do: using your head in real time.

Scripted vs exploratory

In scripted testing, someone designs the cases up front and someone else executes them later — thinking and acting are separated in time. In exploratory testing, they are simultaneous:

  SCRIPTED:     think  →  write case  →  (later)  →  execute
                (the test only does what was anticipated)

  EXPLORATORY:  think + execute + learn   (in a loop, at the same time)
                   ▲                    │
                   └──── what I observed guides the next step ────┘

The two are complementary. Scripted testing (and automation) guarantees repeatable coverage of the expected; exploratory testing finds the unexpected — the bug nobody imagined when writing the cases.

Automation verifies what you already know how to ask. Exploratory testing discovers the questions you haven't asked yet.

The problem: how do you manage something so free?

If exploratory testing has no script, how do you plan, measure and report? The answer is Session-Based Test Management (SBTM), created by James and Jonathan Bach. It provides structure without killing freedom, through three ideas:

• Charter (mission statement): a short sentence that defines the session's focus — what to explore and to what end. E.g.: "Explore file upload focusing on invalid formats and sizes."
• Time-boxed session: an uninterrupted, timed block (typically 60–90 min) dedicated to one charter.
• Notes and debrief: a record of what was tested, bugs, questions and ideas — followed by a quick conversation with the team.

This makes exploratory testing reportable: you can say "I ran 3 sessions on checkout, found 2 bugs and 4 business-rule questions" — a concrete metric for a creative activity.

Heuristics: what guides the investigation

Exploratory testing isn't random because the tester uses heuristics — mental shortcuts that point to where defects usually are. Two widely used ones:

SFDPOT (James Bach) — "tour" the product by dimensions:
  Structure   what the product IS (files, code, hardware)
  Function    what it DOES (features, calculations, error handling)
  Data        what it PROCESSES (inputs, outputs, large/empty data)
  Platform    what it DEPENDS ON (OS, browser, dependencies)
  Operations  how it is USED (usage profiles, environments)
  Time        how TIME affects it (timeouts, time zones, concurrency)

RCRCRC (regression) — where to look when time is short:
  Recent      what changed recently
  Core        the product's essential functions
  Risk        the highest-risk areas
  Configuration  configuration-sensitive items
  Repaired    what was fixed recently
  Chronic     what keeps breaking

Heuristics turn "testing for the sake of it" into "testing with hypotheses" — you attack the system from angles where experience says bugs hide.

Where this fits in the strategy

In the Agile Testing quadrants, exploratory testing is the heart of Q3 (tests that critique the product from the business perspective). It doesn't replace the automation at the base of the pyramid — it combines with it: automation covers repetitive regression and frees the human's time for the investigation that only a human does well.

Conclusion

Exploratory testing is critical thinking applied in real time, and session-based testing is what makes it manageable and reportable. Mastering charters, time-boxed sessions and heuristics like SFDPOT and RCRCRC is what distinguishes the QA who "tests the screen" from the one who investigates the product — and it's where the bugs no script predicted show up.