Exploratory Testing: A Arte de Testar Sem Roteiro

Testes Automatizados · 4 de julho de 2026

📖 7 min de leitura

O Que é Exploratory Testing?

Exploratory Testing (ET) é uma abordagem de teste onde o testador simultaneamente aprende sobre o sistema, projeta testes e os executa. É o oposto de testes scriptados – em vez de seguir um roteiro fixo, o testador usa sua criatividade e experiência para explorar o software.

Características Fundamentais

Aspecto Scripted Testing Exploratory Testing
Planejamento Detalhado antes Simultâneo
Documentação Antes da execução Durante e depois
Abordagem Repetitiva Adaptativa
Criatividade Limitada Alta
Descoberta Busca por defeitos específicos Busca por defeitos inesperados
Melhor para Regressão, compliance Novos features, UX

Por Que Exploratory Testing?

Quando ET Brilha

  • Novos recursos – Quando você não sabe o que esperar
    1. UX testing – Avaliar experiência do usuário
    2. Complexidade – Sistemas com muitas interações
    3. Bugs difíceis – Defeitos que scripts não capturam
    4. Rapid feedback – Quando tempo é curto
    5. Decision making – Determinar se está “pronto”

    Casos de Uso

    Exemplo 1: Nova tela de checkout
    1. O que fazer primeiro? → ET descobre fluxos
    2. O que esperar? → ET revela expectativas reais
    3. O que pode dar errado? → ET encontra edge cases
    Exemplo 2: After refactoring
    1. Funciona como antes? → ET verifica comportamento
    2. Há regressões? → ET busca inconsistências
    3. Performance está ok? → ET sente delays

    Técnicas de Exploratory Testing

    1. Touring Methods (James Whittaker)

    Feature Tour

    # Feature Tour
    "Explore todas as funcionalidades do menu"
    
    

    Ações:

    1. Navegar por cada opção do menu

    2. Ler tooltips e placeholders

    3. Verificar consistência visual

    4. Identificar funcionalidades duplicadas

    landmarks Tour

    # Landmarks Tour
    "Identificar pontos de referência na aplicação"
    
    

    Registrar:

    1. Telas principais (landmarks)

    2. Navegação entre elas

    3. Back button funciona?

    4. Breadcrumbs corretos?

    ####intellectual Tour

    # Intellectual Tour
    "Testar baseado em conhecimento do domínio"

    Foco:

    1. Regras de negócio críticas

    2. Casos de uso principais

    3. Dados de fronteira

    4. Estados inválidos

    2. CSIO (Clue, Specify, Implement, Operate)

    # CSIO Checklist
    
    

    C - Clue (Pista)
    └── O que me chamou a atenção?
    - Link com texto estranho
    - Campo com validação incomum
    - Performance lambatmática

    S - Specify (Especificar)
    └── O que testar?
    - Teste específico para a pista
    - Dados de teste necessários
    - Resultado esperado

    I - Implement (Implementar)
    └── Como testar?
    - Executar teste
    - Observar resultado
    - Documentar comportamento

    O - Operate (Operar)
    └── O que descobri?
    - Bug encontrado?
    - Comportamento inesperado?
    - Oportunidade de melhoria?

    3. Session-Based Testing

    # Session-Based Testing
    
    

    Estrutura

    1. Sessão: 60-90 minutos
    2. Charter: Objetivo claro
    3. Debrief: Resumo ao final

    Template de Charter

    Charter: Testar fluxo de checkout com múltiplos itens =============================================== Cover: Checkout, carrinho, pagamento Test: Adicionar itens, aplicar cupons, escolher frete Oracle: Comportamento esperado de e-commerce

    Session Log

    TempoAçãoObservação
    00:05Adicionou 1 itemOk
    00:08Adicionou item2Total atualiza
    00:12Removeu item1Total recalcula
    00:15Aplicou cupom"CUPOM_VÁLIDO"


    Charter de Testing

    Template de Charter

    # Charter de Testing
    
    

    Identificação

    1. Testador: [Nome]
    2. Data: [Data]
    3. Sistema: [Nome do sistema]
    4. Versão: [Versão]

    Objetivo

    [Testar o quê?] - [Por quê?]

    Cobertura

    1. Funcionalidades a testar
    2. Áreas de foco

    Abordagem

    1. Técnicas a usar
    2. Dados de teste

    Oracle

    1. Como saber se está certo?
    2. Comportamento esperado

    Tempo Estimado

    [ ] 30 min [ ] 60 min [ ] 90 min

    Exemplos de Charters

    Charter 1: Fluxo de Login

    Testar o fluxo de login completo incluindo:
    1. Login com credenciais válidas
    2. Login com credenciais inválidas
    3. Recuperação de senha
    4. Manter sessão ativa
    5. Logout
    Abordagem: Use a técnica de percurso do usuário

    Charter 2: Upload de Arquivos

    Explorar limites de upload de arquivos:
    1. Tipos de arquivo permitidos
    2. Tamanho máximo
    3. Nome com caracteres especiais
    4. Upload simultâneo
    5. Cancelamento de upload

    Charter 3: Relatórios

    Verificar geração de relatórios:
    1. Filtros funcionam?
    2. Exportação para PDF/Excel
    3. Gráficos renderizam?
    4. Dados estão corretos?
    5. Performance com muitos dados?

    Ferramentas de Apoio

    Para Documentação

    Ferramenta Uso
    TestRail Gerenciamento de casos e notas
    qTest Exploratory testing module
    PractiTest Gerenciamento de testes
    Rapid Reporter Tomar notas rapidamente
    Trello Tracking de sessões

    Para Gravação

    # Rapid Reporter
    # Ferramenta simples para Windows que:
    # - Captura screenshots automaticamente
    # - Log de ações com timestamps
    # - Exportação para Excel/HTML
    
    

    # Loom
    # - Gravar tela durante sessão
    # - Compartilhar com equipe
    # - Revisar depois


    Combinando ET com Automação

    Estratégia Híbrida

    ┌─────────────────────────────────────────────┐
    │                                             │
    │   Exploratory Testing                        │
    │   ├── Busca por bugs inesperados            │
    │   ├── Avaliação de UX                      │
    │   └── Context-aware testing                │
    │                                             │
    │           ↓                                 │
    │                                             │
    │   Automação de Testes                      │
    │   ├── Regressão                            │
    │   ├── Testes repetitivos                   │
    │   └── Cobertura de edge cases              │
    │                                             │
    └─────────────────────────────────────────────┘
    

    Fluxo de Trabalho

    1. ET descobre bug → Automatizar para regressão
    2. ET valida fix → Executar teste automatizado
    3. ET explora novo feature → Criar charter
    4. ET identifica padrões → Criar testes automatizados

    Exemplo: Bug Encontrado em ET

    # Bug Report - Exploratory Testing
    
    

    Descoberta

    Durante sessão exploratory no checkout, encontrei um bug:
    1. Usuário adiciona produto
    2. Aplica cupom "DESCONTO10"
    3. Remove o produto
    4. Cupom ainda aparece aplicado!

    Prioridade

    Alta - Usuário pode ser cobrado incorretamente

    Steps to Reproduce

    1. Adicionar produto ao carrinho
    2. Clicar em "Aplicar Cupom"
    3. Inserir "DESCONTO10"
    4. Clicar em "Remover" no produto
    5. Observar que cupom permanece

    Automação

    Criar teste automatizado para prevenir regressão:

    python
    def test_cupom_removido_quando_produto_removido():
    # Setup
    checkout_page.add_product()
    checkout_page.apply_coupon(“DESCONTO10”)

    # Action
    checkout_page.remove_product()

    # Assert
    assert not checkout_page.has_coupon_applied()
    assert checkout_page.coupon_field_is_empty()


    Matriz de Cobertura

    Cobertura por Feature

    Feature ET Automatizado Cobertura Total
    Login 100{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}
    Cadastro 100{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}
    Checkout ⚠️ Parcial 90{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}
    Pagamento 95{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}
    Perfil ⚠️ Parcial 85{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}

    Cobertura por Risco

    Risco Probabilidade Impacto ET Recomendado
    Processamento de pagamento Alta Crítico 2 horas
    Cálculo de frete Média Alto 1 hora
    Upload de imagem Baixa Médio 30 min
    Notificações Média Médio 30 min

    Métricas de Exploratory Testing

    Session Metrics

    Métricas de Sessão

    1. Cobertura
    - Funcionalidades exploradas: X/Y - Tempo gasto por área
    1. Eficiência
    - Bugs encontrados / hora - Defeitos críticos encontrados
    1. Qualidade
    - Bugs duplicados - Bugs únicos válidos
    1. Documentation
    - Notas tomadas - Screenshots capturados - Testes automatizados propostos

    Report Template

    # Relatório de Sessão ET
    
    

    Informações Gerais

    1. Data: [Data]
    2. Testador: [Nome]
    3. Duração: [X horas]
    4. Sistema: [Sistema]

    Resumo

    [Brief description of what was tested and overall assessment]

    Cobertura

    1. Áreas exploradas: [List]
    2. Funcionalidades testadas: [Count]

    Defeitos Encontrados

    IDDescriçãoSeveridadeStatus
    BUG-001Cupom não removidoAltaAberto
    BUG-002.........

    Opportunidades de Automação

    1. [Teste 1] - Prioridade Alta
    2. [Teste 2] - Prioridade Média

    Avaliação Geral

    1. ✅ Sistema pronto para produção
    2. ⚠️ Sistema pronto com restrições
    3. ❌ Sistema NÃO pronto

Conclusão

Exploratory Testing é uma habilidade essencial que complementa testes automatizados. Suas vantagens são:

  1. Flexibilidade – Adapta-se a qualquer situação
  2. Criatividade – Encontra bugs inesperados
  3. Eficiência – Máximo de cobertura em pouco tempo
  4. Contexto – Avalia experiência real do usuário
  5. Descoberta – Identifica oportunidades de melhoria


FAQ

P: ET substitui testes automatizados?
R: Não. ET e automação são complementares. Use ET para descoberta, automação para regressão.

P: Quanto tempo dedicar a ET?
R: Recomenda-se 20-30{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442} do tempo de QA para ET em projetos maduros.

P: Como documentar ET?
R: Use charters, session logs, screenshots e bug reports estruturados.

P: ET funciona em agile?
R: Sim! ET é ideal para sprints curtos onde você precisa de feedback rápido.