…

Gerenciamento de testes exploratórios usando sessões

setembro 27, 2022

O SBTM – Session Based Test Management  (Gerenciamento de testes baseado em sessões) – é o método de gestão de testes exploratórios mais conhecido e largamente usado pela comunidade de testes. Jon Bach, um dos seus criadores, no famoso artigo “Session-Based Test Management“, descreve o nascimento do método da seguinte maneira: “A primeira coisa que notamos durante nossos esforços de reinventar o gerenciamento de teste exploratório foi que os testadores faziam diversas coisas durante o teste que não eram exatamente teste. Neste caso, se fosse necessário rastrear e controlar apenas o teste, seria necessário diferenciar o esforço de execução dos testes das demais atividades. Em função disso, nasceu o gerenciamento por sessões. Cada sessão é composta por um período de tempo ininterrupto e obedece uma missão pré-definida, além disso, uma sessão deve produzir resultados tangíveis e revisáveis”.

Adicionalmente, James Bach, irmão de Jon Bach e também idealizador do SBTM, explica no seu paper intitulado “Exploratory Testing Explained“ o método de gestão por meio de sessões através da seguinte perspectiva: “o gerenciamento de teste baseado em sessões é um método de gestão projetado para tornar o teste exploratório auditável e mensurável”. Ele sintetiza os atributos fundamentais do método de gestão baseado em sessões deste modo: “Em uma sessão de trabalho com um período pré-determinado de tempo, um testador explora o software para cumprir os objetivos de uma missão e ao final apresenta os resultados”. 

Essencialmente o gerenciamento de testes exploratórios baseado em sessões possui os seguintes componentes: missão, sessão, testador e resultados. Vamos revisar detalhadamente cada um destes componentes e entender a sua importância.

 

Missão

A missão indica o objetivo da exploração de forma breve, como se fosse um caso de teste resumido. Porém, a missão descreve o que deve ser testado (não como o teste deve ser executado). Uma missão frequentemente é definida e descrita na hora da execução do teste exploratório, ainda assim, ela pode ser escolhida dentre uma biblioteca ou repositório de missões criadas anteriormente. As missões não devem ser muito detalhadas ou muito genéricas. Não existe um formato universal para descrever as missões, no entanto, Elisabeth Hendrickson, no artigo “Exploratory Testing in an Agile Context”, recomenda que as missões sejam descritas da seguinte forma:

  • Explore (uma estória, funcionalidade, área, risco, etc)
  • Com (recursos, restrições, heurísticas, táticas, etc)
  • Para (descobrir informações, obter respostas, atingir um objetivo)

 

É importante salientar que as missões não são artefatos estáticos e imutáveis. Ao longo do tempo elas são revisadas e aperfeiçoadas a partir de várias origens, como por exemplo:

  • Reuniões/Conversas com usuários, desenvolvedores, gerentes, etc;
  • Estórias de usuário/Requisitos/Manuais;
  • Defeitos;
  • Oportunidades percebidas durante uma sessão de teste exploratório;
  • Softwares concorrentes/similares;
  • Heurísticas;
  • Brainstorms.

 

Sessão

A sessão de teste exploratório abrange um período ininterrupto de tempo com duração média entre 1 a 2 horas. O propósito fundamental da sessão de teste exploratório é cumprir os objetivos de uma missão. Em um mundo ideal, para cada missão, deveria ser executada apenas uma sessão de teste exploratório. Contudo, é possível realizar várias sessões de testes exploratórios para cumprir os objetivos de uma única missão.

As ações tomadas durante a execução de uma sessão são responsabilidade do testador. Além de cumprir o objetivo da missão, o testador tem a liberdade de explorar oportunidades, questões pendentes, ou qualquer coisa relevante para o teste. Além disso, o testador deve investigar e reportar defeitos, assim como, configurar e preparar o ambiente de testes. Uma sessão de teste exploratório normalmente é realizada através das seguintes etapas:

  • Preparação (Setup): Preparação do ambiente de testes, configuração de massa de dados, leitura de manuais, requisitos, diagramas, etc;
  • Especificação (Design): Definição do que será testado (hipóteses) baseados em heurísticas, idéias, checklists, riscos, feeling, etc;
  • Execução (Execution): Execução propriamente dita do teste exploratório para demonstrar se as hipóteses/expectativas da missão foram atendidas (ou não);
  • Oportunidades (Opportunities): Tempo gasto em atividades/explorações/investigações que não estão no escopo da missão;
  • Reporte de defeitos (Bug investigation/Report): Investigação e relato dos defeitos encontrados.

 

Testador

Conforme exposto anteriormente, testes exploratórios não são escritos antecipadamente em um plano ou caso de teste, eles são projetados, executados e refinados (on the fly) durante a exploração com base na intuição, julgamento e experiência do testador. De acordo com o seu famoso artigo “Exploratory Testing Explained”, James Bach declara que o teste exploratório se torna mais interessante quando é observado sob a ótica das habilidades do testador. O testador tem a responsabilidade de usar os métodos que julgar necessários para determinar quais hipóteses e experimentos serão aplicados para demonstrar se a missão de testes foi atendida (ou não). No fim, o que torna o teste exploratório tão eficiente são as habilidades do testador de executar os testes sem a necessidade de instruções detalhadas.

 

Resultados

 Ao final de uma sessão de teste exploratório, é gerado um conjunto de notas que pode ser revisado por um membro da equipe (por exemplo: um líder de testes, um gerente, o cliente, etc). Esta é uma das características fundamentais que diferencia o gerenciamento de testes usando sessões em relação ao teste exploratório ad-hoc tradicional. No paper “How to Manage and Measure Exploratory Testing” Jon Bach compartilha a seguinte recomendação: “durante o teste exploratório o testador deve registrar os resultados no relatório da sessão”. Normalmente o relatório deve incluir a descrição da missão, o nome do testador, notas sobre o que foi testado, o ambiente de testes usado, defeitos encontrados ou que precisam de investigação adicional, entre outras informações. Bach também recomenda a captura de alguns indicadores básicos em relação à distribuição do tempo gasto durante o teste exploratório, por exemplo:

  • Test Execution/Design: Percentual do tempo total gasto na criação e execução dos testes exploratórios;
  • Bug Investigation/Report: Percentual do tempo total gasto na investigação e reporte de defeitos;
  • Setup: Percentual do tempo total gasto em atividades de preparação (estudo, configuração de hardware/software, outras atividades não relacionadas ao teste, etc).

 

Ao final da execução das sessões de testes exploratórios, o testador tem a oportunidade de apresentar o relatório da sessão e as métricas para o líder de testes ou qualquer outro stakeholder com o objetivo de dar visibilidade em relação ao que foi explorado, os problemas encontrados e os próximos passos. Jon Bach, no artigo “How to Manage and Measure Exploratory Testing”, recomenda que a apresentação dos resultados siga a estrutura descrita pelo acrônimo PROOF:

  • P – Past (passado): O que aconteceu durante a sessão?
  • R – Results (resultados): Quais resultados foram encontrados durante a sessão?
  • O – Obstacles (obstáculos): Quais obstáculos dificultaram a exploração?
  • O – Outlook (previsão/perspectiva): O que ainda falta fazer?
  • F – Feelings (sentimentos): Como o testador se sente em relação ao teste ou à qualidade do sistema?

 

Testes exploratórios é uma excelente abordagem para a realização de testes quando não existe um conhecimento prévio sobre o aplicativo que será testado, quando não existem requisitos formais e também para acelerar a descoberta de defeitos em ciclos de desenvolvimento curtos.

 

Time MeloQA

Posts relacionados