Testes Exploratórios de A a Z

O teste exploratório é, na sua definição mais básica, a criação e a execução ao mesmo tempo de um teste. Quando se realiza um teste exploratório, normalmente o testador não tem informações detalhadas sobre o que vai testar e como vai testar.

por Cristiano Caetano

Testes Exploratórios: Revolução ou Padronização de um conhecimento já existente?

"José é um usuário de computador mediano e acabou de entrar num site cujo principal produto é uma Office Suite gratuita que pode ser usada online e é composta por um editor de textos e uma planilha eletrônica. José nunca utilizou este produto; sua experiência anterior se resume ao Microsoft Office e o Open Office, no entanto, vai explorar os principais recursos dessa Suite para ver se vale a pena migrar para essa solução gratuita. Durante o processo de exploração, José usa sua intuição, o seu conhecimento de aplicativos semelhantes e verifica se o comportamento do software confere com o resultado esperado. Quarenta e cinco minutos depois (e cinco defeitos críticos identificados), José desiste de migrar para essa solução gratuita".

"Samuel é um testador, atualmente ele está no terceiro ciclo de testes de um produto da sua empresa que está prestes a ser lançado no mercado. Durante a execução de um teste, Samuel descobre alguns cenários de testes que não estão sendo cobertos pelo plano de teste existente. Baseado no seu conhecimento sobre o público alvo do produto, Samuel acredita que centenas ou até milhares de usuários serão prejudicados caso exista defeitos nesta área do sistema que não está sendo testada adequadamente. O gerente de qualidade diz que não existe tempo e recursos disponíveis para a atualização do plano de testes para cobrir essa falha. Samuel pouco convencido propõe a utilização de uma hora da sua alocação diária durante uma semana para execução de testes exploratórios. Uma semana depois (e uma dúzia de defeitos críticos identificados), o gerente de qualidade está mais confiante em relação ao produto e Samuel tornou-se o responsável pela revisão dos planos de testes".

"Marcelo é um testador e está executando um plano de testes. Durante a execução de alguns testes o aplicativo está aleatoriamente apresentando um comportamento inadequado. Marcelo sabe que se cadastrar um defeito no Bugzilla sem descrever os passos de como reproduzí-lo, o defeito não será consertado ou será definida uma prioridade baixa ao defeito. Ele decide realizar um teste exploratório para tentar reproduzir o defeito e identificar a causa raiz. O processo para a identificação deste problema é difícil, Marcelo precisa garantir que vários componentes do aplicativo interajam entre si; exigindo muitas idas e vindas numa abordagem investigativa. Duas horas depois o defeito é descoberto e são cadastrados no Bugzilla os passos para reproduzí-lo".

Os cenários descritos anteriormente, apesar de hipotéticos, representam situações reais de testes exploratórios. Podemos afirmar que todos nós, de uma forma ou de outra, realizamos testes exploratórios. No entanto, na maioria das vezes, assim como apresentado nos cenários anteriores, os testes exploratórios são realizados de maneira tácita ou informal. Historicamente o teste exploratório, também chamado de teste ad-hoc, era normalmente desencorajado e definido como uma abordagem de pouco valor. Entretanto, James Bach, Cem Kaner, Brian Marick, entre outros profissionais há mais de cinco anos trabalham num esforço de tornar o teste exploratório conhecido e reconhecido como uma técnica de teste de software [2]. O resultado deste trabalho é a sistematização e reconhecimento do teste exploratório como uma técnica formal que pode e deve ser utilizada em paralelo a técnicas de teste convencionais.

Explorando Testes Exploratórios

O teste exploratório é, na sua definição mais básica, a criação e a execução ao mesmo tempo de um teste [2]. Quando se realiza um teste exploratório, normalmente o testador não tem informações detalhadas sobre o que vai testar e como vai testar. O testador se baseia na sua experiência, assim como no conhecimento que ele vai adquirindo sobre o aplicativo durante a execução do teste exploratório. A partir dessa perspectiva, podemos afirmar que o teste exploratório é uma atividade iterativa e empírica de exploração que exige idas e vindas num processo de investigação contínuo onde a intuição, a criatividade e a experiência do testador são indispensáveis para garantir a eficiência do teste. Segundo Cem Kaner [1], não existe necessidade de um testador se especializar em testes exploratórios. Idealmente, todos os testadores deveriam gastar cerca de 25% do seu tempo realizando testes exploratórios, 25% criando e documentando novos casos de teste e 50% executando testes de regressão.

Usualmente, nos testes convencionais os casos de teste são todos predefinidos e cada caso de teste desdobra-se em um conjunto também predefinido de passos que por sua vez descrevem cada estímulo ou interação com o aplicativo que deverá ser realizado pelo testador. No entanto, os testes convencionais são muito dependentes da consistência e estabilidade dos requisitos. Se os requisitos estiverem ambíguos, incompletos ou sendo atualizados constantemente os testes convencionais também serão ambíguos e incompletos.

Nos testes exploratórios, por sua vez, não existe uma forte dependência entre os testes e os requisitos, assim como, não é necessário um planejamento prévio muito detalhado sobre quais testes serão executados; o que torna o teste exploratório uma ótima escolha 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 em metodologias ágeis (como o Extreme Programming) onde não existem documentos de requisitos formais. Por outro lado, o teste exploratório também é utilizado como ferramenta de apoio para a criação de testes convencionais. Por exemplo, durante a escrita de um plano de teste, você poderá realizar testes exploratórios para aumentar o entendimento do funcionamento do aplicativo e criar casos de testes mais efetivos. De forma similar, durante a execução de um teste convencional, você poderá executar testes exploratórios para tentar reproduzir um defeito aleatório e identificar a causa raiz do problema.

Dentre as razões existentes para a realização de testes exploratórios, podemos destacar as seguintes:

• Realização de testes quando não existem requisitos;
• Realização de testes quando existe pouco tempo disponível;
• Realização de testes quando não se conhece o aplicativo a ser testado;
• Realização de testes em ambientes pouco testados pelos testes convencionais;
• Identificação dos passos para tentar reproduzir um defeito aleatório;
• Diagnóstico de comportamentos inesperados;
• Investigação de efeitos colaterais;
• Investigação de defeitos semelhantes;
• Medição de riscos;
• Determinação de defeitos críticos rapidamente;

Testes Exploratórios sob a ótica de um processo empírico

Durante o teste exploratório a palavra de ordem é: "Qual o teste mais importante que eu posso realizar agora?". Esse tipo de questionamento constitui, sem dúvida, imperativo na realização de testes exploratórios.

Lee Copeland, autor do livro "A Practitioner"s Guide to Software Test Design" [3], é um dos poucos autores que conseguiu capturar as atividades realizadas durante o teste exploratório sob o ponto de vista de um processo empírico e iterativo. Segundo Copeland, um possível processo que pode ser aplicado durante a execução de um teste exploratório, pode ser definido da seguinte forma:

• Criação de uma hipótese. Um modelo mental representando o funcionamento supostamente correto da área do aplicativo que será testada.
• Planejar um ou mais cenários de teste que possam comprovar se a hipótese é verdadeira;
• Aplicar os testes e observar os resultados;
• Avaliar os resultados contra a hipótese levantada no primeiro passo;
• Repetir esse processo até que a hipótese seja comprovada (ou não);

Abordagens formais para a geração de hipóteses

Test Oracle

Test Oracle é uma técnica comumente empregada para auxiliar o testador a predizer o funcionamento supostamente correto do aplicativo ou de determinada do aplicativo. A idéia fundamental dos Test Oracles é garantir consistência por meio da observação e comparação. Digamos, por exemplo, que um novo portal de vendas online está sendo construído para substituir um outro mais antigo. Durante a realização dos testes do novo portal, o portal antigo sempre será usado como referência; ele será um Test Oracle para garantir que o comportamento do novo portal seja consistente. Por outro lado, vamos supor que um aplicativo de contabilidade sempre exibe um preview dos relatórios antes iniciar a impressão. O Test Oracle nesse caso é a consistência desse comportamento em todo o aplicativo; ou seja, poderíamos considerar um defeito caso algum relatório não exibisse o preview antes de iniciar a impressão.
James Bach, no documento "General Functionality and Stability Test Procedure for Certified for Microsoft Windows Logo" [5], descreve os procedimentos para a realização de testes exploratórios a fim de avaliar a funcionalidade e estabilidade dos aplicativos com o propósito de conceder um certificado de compatibilidade com o Windows 2000. Bach, entre diversas informações e dicas sobre como realizar testes exploratórios, descreve um padrão genérico para a identificação de Test Oracles sob o ponto de vista da consistência:

• Consistência com a proposta: o comportamento deve ser consistente com a sua proposta;
• Consistência com o resto do aplicativo: o comportamento deve ser consistente com o comportamento de outras áreas do aplicativo;
• Consistência histórica: o comportamento deve ser consistente ao longo do tempo;
• Consistência com aplicativos semelhantes: o comportamento deve ser consistente com o comportamento de aplicativos similares, concorrentes, etc;

Heurística

Heurística é uma boa prática utilizada intuitivamente por testadores experientes. A heurística se baseia no bom senso e na experiência de quem a utiliza; é uma forma de auxiliar o testador a imaginar cenários de teste rapidamente sem ter muitos detalhes sobre o aplicativo a ser testado. Na verdade, podemos afirmar que a heurística é uma técnica cuja principal função é auxiliar o testador a fazer suposições com algum embasamento formal. A idéia fundamental da heurística é evitar que as suposições sejam realizadas por meio de chutes a esmo. James Bach, um dos criadores e defensores da utilização de testes exploratórios, publicou um ótimo guia chamado "Heuristic Test Strategy Model" [4] descrevendo várias heurísticas que podem ser aplicadas durante a criação de uma estratégia de testes exploratórios e até mesmo para testes convencionais. Do ponto de vista prático, vamos analisar a utilização dessa técnica para identificar cenários de teste fictícios que poderiam ser realizados numa sessão de testes exploratórios, conforme apresentando a seguir:

• (Baseado na experiência do testador): baseado na minha experiência em outros projetos, os aplicativos que suportam línguas internacionais normalmente não funcionam direito em plataformas com uma língua diferente da língua nativa dos desenvolvedores. Freqüentemente os desenvolvedores esquecem hard-coded alguma constante que varia conforme a língua (como por exemplo "C:\Arquivos de Programas\" ) que provavelmente faria o aplicativo gerar uma exceção numa plataforma diferente (como por exemplo Chinês Simplificado). Neste caso, durante a execução dos testes exploratórios devemos executar um conjunto de testes básicos numa plataforma de língua oriental para confirmar se não existem defeitos críticos.
  
  
• (Baseado na cobertura das plataformas suportadas): os requisitos definem que o aplicativo deve gerar um relatório no formato HTML que deve ser visualizado em qualquer browser. No entanto, todos os testes convencionais foram realizados somente contra a última versão do Internet Explorer e do Firefox. Neste cenário, durante a execução dos testes exploratórios devemos confirmar se o relatório pode ser visualizado em todos os outros browsers disponíveis no laboratório de testes.
  
  
• (Baseado na verificação dos limites extremos): os requisitos definem que os arquivos que serão utilizados para popular o banco de dados de clientes deverão ser preenchidos com 180 colunas fixas. Todos os testes convencionais foram feitos com arquivos sem erros e preenchidos adequadamente. Durante os testes exploratórios devemos utilizar arquivos vazios, arquivos com mais de 180 colunas e arquivos com menos de 180 colunas para garantir que o aplicativo está identificando e avisando adequadamente o usuário que existem inconsistências nos arquivos.

Phoenix Checklist

A Phoenix checklist é basicamente um conjunto de perguntas que podem ser aplicadas a qualquer contexto e foi desenvolvida nos Estados Unidos pela CIA. Este checklist é normalmente empregado para ajudar os agentes da CIA a visualizar os problemas por diversas perspectivas diferentes. No ponto de vista dos testes exploratórios, este checklist serve para auxiliar o testador a identificar novos cenários de teste ou para identificar a causa raiz um defeito. A Phoenix checklist é dividida em um conjunto de perguntas para identificar e explorar o problema em que se está lidando (Figura 1) e um outro conjunto de perguntas para auxiliar a identificar um possível plano para a resolução do problema (Figura 2).


Figura 1. Checklist para identificar o problema em questão.


Figura 2. Checklist para identificar a possível resolucao do problema.

Diagrama de Ishikawa (Cause-and-Effect Diagram)

O diagrama de Ishikawa, também conhecido como diagrama de causa e efeito tem por objetivo determinar as origens de um problema por meio da geração de uma lista detalhada das suas causas e as sua sub-causas. O diagrama de causa e efeito tem a função de nos ajudar a identificar rapidamente as áreas do aplicativo que estão sofrendo problemas, os tipos de problemas que estamos lidando e quais problemas precisarão de uma investigação mais detalhada, como pode ser visto no exemplo descrito na Figura 3.


Figura 3. Diagrama de causa e efeito.

Five Whys

Five Whys é uma outra técnica cujo propósito é promover uma análise profunda do problema em que estamos lidando por meio do questionamento contínuo. Nesta técnica você deverá perguntar "Por que?" cinco vezes e prover as respostas adequadas para cada pergunta. Ao final da quinta pergunta, você deverá analisar as respostas em busca da causa raiz do problema. Uma vez identificada a possível causa raiz, devemos criar cenários de testes exploratórios para realizar uma investigação mais detalhada, como pode ser visto no exemplo abaixo:

Por que todos os testes de impressão de relatórios falharam?
Porque os dados parecem estar inconsistentes.

Por que os dados parecem estar inconsistentes?
Porque muitos dos testes de cadastro e consulta de cliente também falharam.

Por que muitos dos testes de cadastro e consulta de cliente também falharam?
Porque esta foi a primeira vez que os dados foram importados para essa plataforma.

Por que esta foi a primeira vez que os dados foram importados para essa plataforma?
Porque somente agora foi contratado um programador para realizar essa tarefa.

Por que somente agora foi contratado um programador para realizar essa tarefa?
Por que não existia ninguém no nosso time que tivesse experiência nessa plataforma para realizar esta tarefa.

No exemplo fictício descrito anteriormente, podemos identificar que vários testes falharam em função dos dados estarem inconsistentes em determinada plataforma. Neste caso, devemos planejar um conjunto de testes exploratórios para esta plataforma a fim de identificar problemas críticos rapidamente.

Planejamento dos Testes Exploratórios

Testes Exploratórios (Session Based)

O teste exploratório baseado em sessões [6][7] é uma estratégia utilizada para tornar o teste exploratório mais efetivo e com objetivos mais claros. Nesta abordagem o teste exploratório é realizado em sessões de cerca de 60 minutos, podendo variar de 45 a 90 minutos. A idéia principal de uma sessão é garantir que durante esse período de tempo o testador fique totalmente concentrado na execução de testes e não seja interrompido para atender ligações telefônicas, reuniões, etc.

Por outro lado, cada sessão deve cumprir uma missão previamente definida. Na verdade, a missão define o que vai ser testado durante a sessão e qual será a estratégia de teste adotada para realizar o teste exploratório. A missão do teste exploratório pode ser definida numa tabela descrevendo as estratégias de testes que serão utilizadas. Nesta tabela, podemos adicionar critérios de sucesso e falha, o status do teste, defeitos encontrados, entre outras informações dependendo da sua necessidade (Figura 4).


Figura 4. Estratégia e teste exploratório baseado em sessões.

Por outro lado, devemos esclarecer que as estratégias de teste devem descrever a intenção do que deve ser testado durante o teste exploratório e não como o teste deve ser realizado; dessa forma estaríamos descrevendo os passos de um caso de teste convencional ao invés de um teste exploratório. A estratégia de teste pode e deve ser criada a partir das abordagens formais para a geração de hipóteses, conforme discutimos anteriormente. No entanto, devemos lembrar que a missão é apenas orientação do que deve ser testado durante a sessão de teste exploratório, e não deve ser necessariamente seguida à risca. A missão não de ser considerada como uma burocracia, mas uma diretriz do que deve ser abordado durante a sessão de teste exploratório. Em termos práticos, isto significa que o testador deve ter a liberdade de explorar com maior profundidade determinada área do aplicativo em detrimento de outra, mesmo que isso seja contra o que estiver definido na estratégia de teste; ou até mesmo testar áreas que nem estão definidas na estratégia.

Testes Exploratórios (Free Style)

O teste exploratório estilo livre (Free Style) é o oposto do teste exploratório baseado em sessões. Nesta modalidade, não existe nenhuma definição formal de quanto tempo ou o que será testado. Esta abordagem é normalmente utilizada por testadores realmente experientes para identificar defeitos críticos quando não existe muito tempo para a criação de estratégias formais.

Para saber mais...

[1] An Exploratory Testing Workshop Report
http://www.testingcraft.com/exploratory-pettichord.html

[2] Exploring Exploratory Testing
http://www.testingeducation.org/a/explore.pdf

[3] A Practitioner"s Guide to Software Test Design
http://www.amazon.com/gp/product/158053791X/102-4304464-7157735?v=glance&n=283155

[4] Heuristic Test Strategy Model by James Bach
http://www.satisfice.com/tools/satisfice-tsm-4p.pdf

[5] General Functionality and Stability Test Procedure for Certified for Microsoft Windows Logo
http://www.satisfice.com/tools/procedure.pdf

[6] Session Based Test Management
http://www.satisfice.com/articles/sbtm.pdf

[7] Adventures in Session-Based Testing
http://www.workroom-productions.com/papers/AiSBTv1.2.pdf