Skip to main content

Execução de Testes Exploratórios

Objetivo desta página

Esta página descreve de forma profunda, prática e operacional como ocorre a Execução de Testes Exploratórios na DBSeller. Diferentemente da execução de planos e casos de teste formais, esta etapa tem como foco explorar o sistema além do roteiro, buscando falhas, comportamentos inesperados e riscos que não foram antecipados durante o planejamento.

Testes exploratórios existem para responder a uma pergunta simples, porém poderosa:

O sistema realmente se comporta bem quando alguém o utiliza fora do caminho ideal?

Nesta etapa, o QA deixa de ser apenas executor de cenários e passa a atuar como investigador do comportamento do sistema.

2. O que são Testes Exploratórios

Testes exploratórios são testes realizados de forma intencionalmente não roteirizada, baseados em:

  • Conhecimento do sistema

  • Entendimento das regras de negócio

  • Experiência do QA

  • Observação de comportamentos

Eles não substituem testes planejados. Eles complementam.

Enquanto o plano de teste valida o que foi definido, o teste exploratório busca descobrir:

  • O que não foi pensado

  • O que foi mal interpretado

  • O que se comporta diferente do esperado

3. Por que Testes Exploratórios são essenciais

Mesmo com um planejamento sólido, é impossível prever todos os comportamentos possíveis de um sistema complexo.

Testes exploratórios ajudam a identificar:

  • Bugs escondidos

  • Falhas de usabilidade

  • Inconsistências entre telas

  • Comportamentos erráticos

  • Erros causados por sequências não previstas

Tabela comparativa:

Teste Planejado Teste Exploratório
Segue roteiro Segue comportamento
Valida regras conhecidas Descobre riscos ocultos
Resultado esperado definido Resultado observado
Estruturado Investigativo

4. Quando executar Testes Exploratórios

Testes exploratórios devem ser executados:

  • Após a execução dos testes funcionais principais

  • Após correções de bugs críticos

  • Em sistemas com alto impacto ao usuário

  • Quando há mudanças significativas de comportamento

Eles não devem ser executados:

  • Sem conhecimento prévio da funcionalidade

  • Como substituição dos testes planejados

5. Mentalidade do QA em Testes Exploratórios

Durante testes exploratórios, o QA deve adotar uma postura ativa e questionadora:

  • “E se o usuário fizer isso diferente?”

  • “E se ele pular essa etapa?”

  • “E se os dados estiverem fora do padrão?”

  • “E se o fluxo for interrompido?”

Aqui, o QA testa como o usuário pode usar, não como ele deveria usar.

6. Fluxo geral da Execução de Testes Exploratórios

[Conhecer a Funcionalidade]
            |
            v
[Definir Objetivo da Exploração]
            |
            v
[Executar Ações Aleatórias e Variadas]
            |
            v
[Observar Comportamentos]
            |
            v
[Registrar Achados]
            |
            v
[Analisar Risco]

Esse fluxo pode se repetir diversas vezes durante a exploração.

7. Tipos de Exploração

7.1 Exploração de Fluxo

Explora caminhos alternativos, não previstos no plano de teste.

Exemplos:

  • Pular etapas

  • Voltar páginas

  • Repetir ações rapidamente

7.2 Exploração de Dados

Explora variações de dados:

  • Campos vazios

  • Dados extremos

  • Combinações improváveis

7.3 Exploração de Comportamento

Explora ações do usuário:

  • Cliques repetidos

  • Ações simultâneas

  • Uso fora da ordem

7.4 Exploração de Usabilidade

Avalia:

  • Clareza das mensagens

  • Facilidade de uso

  • Fluxos confusos

Perfeito, agora ficou claro 👍
Abaixo está apenas o ITEM 8, reescrito do zero, em versão final, no formato de manual passo a passo, usando exemplos práticos e referenciando explicitamente os tipos de exploração definidos no Item 7.

Pode colar direto na wiki como o Item 8 da página Execução de Testes Exploratórios.

8. Execução passo a passoprática dos Testes Exploratórios por tipo de exploração

Após compreender o conceito e a mentalidade dos testes exploratórios, o QA deve colocar a exploração em prática de forma organizada e intencional, aplicando diferentes tipos de exploração, conforme definidos no Item 7.

Este item descreve como executar, na prática, cada tipo de teste exploratório, com exemplos reais e orientações claras.

8.1 PreparaçExecução de Testes Exploratórios de Fluxo

AntesOs testes exploratórios de iniciar:fluxo têm como objetivo validar caminhos alternativos, não previstos no plano de teste ou fora da ordem esperada.

Aqui o QA explora como o usuário pode navegar, e não como o sistema espera que ele navegue.

Passo a passo

  1. Identificar o fluxo principal validado nos testes planejados

  2. Escolher um ponto do fluxo para desvio

  3. Executar ações fora da ordem esperada

  4. Observar como o sistema reage

  5. Registrar comportamentos inesperados

Exemplos práticos

  • Acessar o relatório diretamente sem passar pela tela principal da escola

  • Alternar rapidamente entre diferentes escolas e gerar relatórios em sequência

  • Voltar para a tela de cadastro após gerar o relatório e tentar gerar novamente sem atualizar a página

O QA deve observar se:

  • ConhecerO arelatório funcionalidadegerado corresponde à escola correta

  • TerDados ambienteantigos estávelnão são reaproveitados indevidamente

  • SaberO osistema objetivomantém daconsistência exploraçãoentre navegações

8.2 Execução livrede Testes Exploratórios de Dados

Os testes exploratórios de dados têm foco em variações e conscientecombinações de informações, indo além dos dados usados nos cenários planejados.

DuranteO objetivo é identificar falhas causadas por dados incompletos, extremos ou inesperados.

Passo a execução:

passo

    1. NãoIdentificar seguiros roteiroprincipais fixodados envolvidos na funcionalidade

    2. Variar açvalores, quantidades e combinações

    3. Executar a funcionalidade após cada variação

    4. Observar respostasimpactos dono sistemacomportamento e no resultado

    Exemplos práticos

    • Escola com muitos cursos cadastrados

    • Escola sem cursos ativos

    • Escola com cursos ativos e inativos misturados

    • Escola com grande quantidade de Atos Legais

    • Escola sem gestor cadastrado

    O QA deve verificar se:

    • Cursos inativos são corretamente ocultados

    • O relatório mantém layout mesmo com muitos dados

    • Ausência de dados não gera erros ou informações incorretas

    8.3 ObservaçExecução ativade Testes Exploratórios de Comportamento

    Os testes exploratórios de comportamento simulam ações reais e, muitas vezes, impulsivas do usuário.

    Aqui o QA explora o sistema como alguém que não conhece o fluxo ideal.

    Passo a passo

    1. Executar ações repetidas ou rápidas

    2. Interromper fluxos no meio da execução

    3. Repetir ações já concluídas

    4. Alternar funcionalidades sem concluir processos

    Exemplos práticos

    Na geração do relatório de dados da escola:

    • Clicar várias vezes seguidas no botão de gerar relatório

    • Gerar relatório enquanto outra ação ainda está em processamento

    • Alterar dados da escola e gerar o relatório imediatamente

    O QA deve observar:

    • MensagensSe exibidaso sistema gera relatórios duplicados

    • RespostasSe inesperadashá travamentos ou lentidão

    • LentidãSe o ourelatório travamentosreflete os dados mais recentes

    8.4 RegistroExecução dosde achadosTestes Exploratórios de Usabilidade

    Os testes exploratórios de usabilidade avaliam como o sistema se comunica com o usuário, mesmo quando não há erro técnico.

    Aqui o QA atua como usuário final crítico.

    Passo a passo

    1. Observar mensagens exibidas pelo sistema

    2. Avaliar clareza das informações

    3. Identificar fluxos confusos ou pouco intuitivos

    4. Verificar se o sistema orienta corretamente o usuário

    Exemplos práticos

    • O sistema deixa claro qual escola está sendo usada no relatório?

    • O usuário entende por que um curso não aparece no relatório?

    • O relatório apresenta informações de forma legível e organizada?

    Nem todo achado de usabilidade vira bug.bug, mas todo achado relevante deve ser registrado.

    8.5 Registro dos achados por tipo de exploração

    Durante a execução exploratória, o QA deve registrar qual tipo de exploração foi utilizado, pois isso ajuda na análise posterior e na tomada de decisão.

    Tabela de classificação:apoio:

    inativoexibidono
    AchadoTipo de exploração AçãoExemplo de achado
    Bug funcionalFluxo RegistrarRelatório buggerado com dados de escola incorreta
    InconsistênciaDados AvaliarCurso impacto
    MelhoriaSugerir melhoriarelatório
    Comportamento esperado ApenasRelatório registrarduplicado ao clicar rapidamente
    UsabilidadeFalta de clareza sobre dados omitidos

    Esse registro aumenta a rastreabilidade e facilita correções futuras.

    8.6 Relação entre tipos de exploração e bugs encontrados

    Nem todo tipo de exploração gera bug, mas todos ajudam a aumentar a cobertura real.

    Fluxo de consolidação:

    [Execução Exploratória]
        |
        v
[Achados por Tipo]
        |
        v
[Análise de Impacto]
        |
        v
[Bug | Melhoria | Observação]

    Isso ajuda o QA a justificar tecnicamente:

    • por que um bug foi encontrado

    • por que uma melhoria foi sugerida

    • por que algo foi apenas registrado

    8.7 Resultado esperado da execução por tipo de exploração

    Ao aplicar corretamente os tipos de exploração definidos no Item 7, espera-se que o QA:

    • Descubra falhas fora do roteiro planejado

    • Aumente a cobertura comportamental do sistema

    • Identifique riscos reais de uso

    • Contribua para a melhoria contínua da qualidade

    A execução exploratória por tipo transforma curiosidade em método, e observação em valor para o produto.

    Se quiser, no próximo passo posso:

    • alinhar esse item com registro de evidência e bug

    • criar um checklist rápido de exploração

    • ou integrar esse item com análise de risco e Go / No-Go

    9. Exemplos práticos de Testes Exploratórios

    Exemplo 1 – Relatório de Dados da Escola

    Explorações possíveis:

    • Gerar relatório várias vezes seguidas

    • Gerar relatório sem dados obrigatórios

    • Alternar entre escolas rapidamente

    Possíveis achados:

    • Erros intermitentes

    • Lentidão

    • Falha de atualização

    Exemplo 2 – Fluxo fora do plano

    • Acessar relatório sem passar pela tela principal

    • Alterar dados da escola e gerar relatório sem atualizar a página

    10. Registro de evidências em Testes Exploratórios

    Mesmo sendo não roteirizados, testes exploratórios devem gerar evidências.

    Exemplos:

    • Prints

    • Vídeos curtos

    • Descrição clara do comportamento observado

    11. Quando um achado vira bug

    Fluxo de decisão:

    [Achado]
    |
    v
[Contraria regra ou expectativa?]
      |            |
     Não           Sim
      |            |
      v            v
[Registrar como nota] [Registrar Bug]

    12. Relação com Testes Planejados

    Testes exploratórios:

    • Não substituem testes planejados

    • Não dispensam cenários BDD

    • Aumentam cobertura real

    Eles são complemento estratégico.

    13. Boas práticas em Testes Exploratórios

    • Executar com foco e objetivo

    • Registrar tudo que for relevante

    • Não confiar apenas na memória

    • Compartilhar achados com o time

    14. Resultado esperado dos Testes Exploratórios

    Ao final da execução exploratória, espera-se:

    • Identificação de falhas não previstas

    • Melhor compreensão do sistema

    • Aumento da qualidade percebida

    15. Conclusão

    A Execução de Testes Exploratórios é o momento em que o QA exerce seu papel mais analítico e investigativo.

    É nessa etapa que o sistema é realmente desafiado, fora do caminho ideal, revelando comportamentos que roteiros formais não conseguem capturar.

    Na DBSeller, testes exploratórios são parte essencial da qualidade, e não uma etapa opcional.

Back to top