Blog > Testes exploratórios (Parte 1): Introdução

13/jan

Este artigo descreve ao leitor o que são testes exploratórios, suas características e benefícios. Ao longo do artigo, comparamos testes puramente ad hoc em relação a testes exploratórios, além disso, discutimos como é possível usar heurísticas para tornar o teste exploratório uma disciplina que possa ser formalmente descrita, ensinada a outras pessoas e usada em larga escala.

Introdução

É da natureza dos testadores pensar em situações extremas, condições alternativas e caminhos incomuns. Mesmo que não faça parte de um plano formal ou de um roteiro pré-determinado de testes, todo testador profissional, tem o hábito de improvisar testes complementares em diversas situações, como por exemplo:

  • Após averiguar se um defeito foi corrigido, os testadores frequentemente improvisam testes informais para complementar as abordagens de testes tradicionais;
  • Quando um defeito é detectado durante a execução de um teste tradicional, frequentemente o testador executará testes informais para analisar e isolar o defeito a fim de determinar os passos para reproduzi-lo;
  • Para explorar as variações de um defeito com o objetivo de determinar se existe defeitos relacionados ou parecidos;
  • Para conhecer o comportamento de um sistema ou funcionalidade quando não existem requisitos.

Estes testes complementares, independente dos testadores estarem conscientes do que estão fazendo, representam uma abordagem de teste que não obedece uma estrutura rígida frequentemente chamada testes ad hoc. De acordo com o SWEBOK - Software Engineering Body of Knowledge, o teste ad hoc é provavelmente a abordagem de testes mais usada na área de teste de software. No entanto, o SWEBOK não descreve o que é um teste ad hoc. Na literatura especializada em teste de software, não existe também um consenso entre os autores sobre testes ad hoc. No entanto, quando o termo teste ad hoc é mencionado, sempre é associado a idéia de testes informais, aleatórios, superficiais e desorganizados, ou seja, os testadores encontram defeitos acidentalmente, sem terem utilizado nenhuma metodologia, planejamento ou técnica de projeto de casos de testes. Além disso, frequentemente é desencorajado e rotulado como uma abordagem de testes ineficiente que agrega pouco valor.

Chris Agruss e Bob Johnson no seu artigo "Ad Hoc Software Testing: A perspective on exploration and improvisation" afirmam: "De maneira geral, os gerentes de desenvolvimento são céticos em relação a testes ad hoc. Para os gerentes, é inconcebível uma equipe de testadores habilidosos e caros consumirem os escassos recursos por meio da execução de testes de natureza subjetiva e que provavelmente nunca serão executados novamente.

Dessa forma, precisamos primeiro estabelecer o significado de "ad hoc" para termos um melhor entendimento sobre o que é um "teste ad hoc". Segundo a Wikipédia, ad hoc é uma expressão latina que significa "para esta finalidade" ou "com este objetivo". Em engenharia de software, a expressão ad hoc é utilizada para designar ciclos completos de construção de softwares que não foram devidamente projetados em razão da necessidade de atender a uma demanda específica do usuário, ligada a prazo, qualidade ou custo. A expressão também é citada no nível 1 do CMMI, quando a coleta de dados para indicadores é feita ad hoc, ou seja, para resolver determinado problema ou realizar uma tarefa específica. Modelos informais utilizados pelo desenvolvedor de software costumam ser ad hoc, como rabiscar uma idéia para obter maior clareza e simplificação da realidade. Porém, esses modelos não oferecem uma linguagem básica que possa ser compartilhada com outras pessoas facilmente.

Uma das melhores definições sobre teste ad hoc pode ser encontrada no glossário de termos do ISTQB (International Software Testing Qualifications Board). Neste glossário, teste ad hoc significa: "Teste realizado informalmente sem a preparação ou utilização de técnicas de projeto de teste reconhecidas, e sem definição prévia dos resultados esperados"

Com base no que foi exposto, podemos determinar que teste ad hoc é uma abordagem de teste que apresenta as seguintes características fundamentais:

  • É informal e não obedece um processo ou metodologia pré-estabelecido;
  • É destinado a atender a uma necessidade específica ou resolver um problema imediato;
  • Tem caráter temporário;
  • Não é aplicável ou reutilizável em outros casos;
  • Não existe definição prévia dos resultados esperados;
  • Não é planejado ou preparado antecipadamente.

Testes exploratórios

Teste exploratório é uma abordagem de testes que enfatiza as habilidades do testador em tomar decisões sobre o que será testado durante a execução do teste ao invés de seguir um roteiro previamente planejado. No entanto, o conceito não é novo. Glenford Myers em 1979, no seu livro chamado "The Art of Software Testing", já preconizava conceitos embrionários de testes de natureza exploratória, quando discutia técnicas de testes de suposição de erros (do inglês: "Error Guessing Testing").

Teste exploratório é muitas vezes confundido ou usado como sinônimo de teste ad hoc. No entanto, podemos afirmar que teste exploratório é um tipo de ad hoc, já que ambos são testes não sistemáticos que dependem da experiência e intuição do testador. No entanto, as diferenças param por aqui, já que no teste exploratório temos uma estrutura mais sofisticada em comparação com o teste puramente ad hoc.

Para consolidar estas diferenças, o teste exploratório nos últimos anos tem sido alvo de muitas discussões, encontros, artigos e livros. O objetivo deste debate é enfatizar as características necessárias para a realização do teste exploratório a fim de torná-lo uma disciplina que possa ser formalmente descrita, ensinada a outras pessoas e usada em larga escala.

O termo "teste exploratório" foi usado pela primeira vez por Cem Kaner, no seu livro Testing Computer Software em 1999. No livro, ele descreve o teste exploratório como uma abordagem informal que não requer planejamento prévio e documentação detalhada. Kaner descreve testes exploratórios como testes "on the fly" da seguinte forma (tradução livre): "Não importa quantos ou quais tipos de casos de testes você tenha criado e planejado, cedo ou tarde eles serão executados e suas opções se esgotarão. Em certo ponto, você não irá planejar ou criar novos casos de testes até o início do próximo ciclo de testes. Mas você poderá continuar a testar. Confie nos seus instintos, execute qualquer teste que vier na sua cabeça, sem gastar muito tempo preparando ou documentando. Tente qualquer teste que seja promissor, mesmo se o teste for similar a outros que você já tenha executado. O sistema está sendo corrigido e muitas coisas poderão mudar. Talvez muitos dos casos de testes formais tornem-se obsoletos na próxima versão. Ao invés de perder tempo planejando, preparando e escrevendo precocemente casos de testes formais, tente alguns testes exploratórios, ou seja, qualquer coisa que vier na sua mente".

Em julho do ano de 1999 foi realizado um workshop na cidade de Cupertino/CA chamado "Los Altos Workshop on Software Testing (LAWST 7)" cujo principal objetivo era a discussão acerca de testes exploratórios. Ao final do workshop, os participantes chegaram a um consenso sobre as características fundamentais que diferenciavam o teste exploratório do teste ad hoc:

  • Interativo;
  • Cognição e execução concorrente;
  • Criatividade;
  • Direcionado a resultados rápidos;
  • Documentação leve.

Brian Marick no artigo "Interactions and Improvisational Testing" também descreve diversos elementos associados a testes exploratórios, tais como:

  • Uma mescla entre projeto e execução de testes. É um contraste direto em relação a processos tradicionais onde os testes são projetados primeiro para então serem executados posteriormente;
  • O testador aprende sobre o produto enquanto o testa;
  • Ênfase em criatividade e espontaneidade.

No artigo "Evolving Understanding About Exploratory Testing", Michael Bolton relaciona os seguintes aspectos como sendo exclusivos de testes exploratórios:

  • O projeto, execução, interpretação e aprendizado são realizados pela mesma pessoa;
  • O projeto, execução, interpretação e aprendizado acontecem juntos, ao invés de serem executados em momentos diferentes no tempo;
  • O testador faz as suas escolhas sobre o que será testado, quando testar e como testar, ao invés de seguir cegamente um roteiro;
  • O testador enfoca em revelar novas informações sobre o produto, ao invés de confirmar coisas já conhecidas sobre o produto;
  • Tudo o que o testador aprendeu de novo durante o teste, incluindo o resultado do último teste, serve como subsídio para decidir o que será testado a seguir;
  • O testador pode usar qualquer tipo de ferramenta automática para apoiar o seu teste ou decidir não usar nenhuma ferramenta;
  • O testador pode variar diversos aspectos durante a execução dos seus testes, ao invés de repeti-los da mesma forma continuamente.

James Bach em 2003, no seu famoso artigo "Exploratory Testing Explained" descreve o teste exploratório da seguinte forma: "Aprendizado, projeto e execução simultânea dos testes". Ao longo do artigo, Bach compara o teste exploratório com a solução de um jogo de quebra-cabeças. Segundo Bach, quando resolvemos um quebra-cabeça, normalmente temos poucas informações disponíveis sobre como as peças se encaixam e por onde começar. Frequentemente, aprendemos sobre o quebra-cabeça enquanto resolvemos ele por meio meio de um processo que exige idas, vindas, assim como, mudanças de planos. Conforme resolvemos o quebra-cabeça, novas idéias emergem num fluxo contínuo mais ou menos sistemático. Cada momento exige a atenção, percepção e intuição de quem está jogando, além disso, a solução do quebra-cabeça depende da experiência de quem está jogando, afinal o jogador pode usar macetes aprendidos durante a resolução de outros quebra cabeças. Bach, afirma que o teste exploratório se torna mais interessante e sofisticado quando observado sob a ótica das habilidades do testador. O que torna o teste exploratório tão eficiente e eficaz são as habilidades do testador de ouvir, observar, pensar e relatar rigorosamente os testes sem a necessidade de instruções detalhadas.

Em 2006, Cem Kaner, James Bach, Jonathan Bach, Scott Barber, Tim Coulter, Rebecca Fiedler, David Gilbert, Marianne Guntow, James Lyndsay, Robert Sabourin, Adam White, entre outros especialistas em teste de software realizaram um encontro chamado "Exploratory Testing Research Summit" e posteriormente o "Workshop on Heuristic and Exploratory Techniques". O objetivo desses encontros era alinhar as visões sobre o que era teste exploratório, seu objetivo e definição. Como resultado, foi criada a seguinte definição que sintetizava o significado do que é um teste exploratório (tradução livre): "Teste exploratório de software é um estilo de teste de software que enfatiza a liberdade pessoal e responsabilidade de um testador para continuamente otimizar o valor do seu trabalho por meio da perspectiva de que o aprendizado (relacionado aos testes), o projeto de testes, a execução dos testes e a interpretação dos resultados dos testes são mutuamente complementares e realizadas paralelamente ao longo de todo o projeto".

Hipóteses e experimentos

Como vimos anteriormente, muitas definições foram atribuídas ao teste exploratório, no entanto, Lee Copeland, no seu livro "A Practitioner"s Guide to Software Test Design", foi 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. 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 sistema que será testado;
  • 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).

Elisabeth Hendrickson, no seu artigo chamado "Exploratory Testing in an Agile Context", complementa esse cenário (tradução livre): "Quando nós projetamos testes durante uma exploração, nós temos uma hipótese sobre como o software deveria se comportar. Talvez suspeitemos que o software vai exibir uma mensagem de erro em uma situação específica ou queremos apenas confirmar se o software apenas funciona. Em ambas as situações, nós pensamos em um pequeno experimento e então o executamos imediatamente. Estes experimentos nos ensina sobre o comportamento do software. Nós aprendemos como ele funciona, o que funciona e o que não funciona. Quanto mais nós aprendemos como o software funciona e as circunstâncias em que ele não funciona, melhores serão os novos experimentos".

Ao invés de perguntar qual é o próximo teste que devo executar, o testador exploratório perguntaria: "Qual seria o melhor teste que eu posso executar agora?". Essa atitude retrata a definição mais básica do teste exploratório onde é enfatizada a liberdade pessoal e responsabilidade do testador para continuamente otimizar o valor do seu trabalho. Os seja, no teste exploratório, o grau de detalhe e profundidade do que é testado é aprimorado ao longo da execução dos testes.

Com base no que foi exposto, podemos afirmar que os testes exploratórios não são definidos antecipadamente em um plano ou roteiro de testes, eles são dinamicamente projetados, executados e aprimorados durante a exploração com base na intuição, julgamento e experiência do testador. Dessa forma, uma vez dado ao testador um objetivo/meta de teste, é de sua responsabilidade usar os mecanismos e artifícios necessários para inventar, improvisar e, até mesmo, aplicar técnicas formais de projeto de casos de testes para determinar quais hipóteses e experimentos serão executados para demonstrar se o objetivo/meta de teste foi atingido ou não.

No entanto, a fim de tornar o teste exploratório uma disciplina que possa ser formalmente descrita, ensinada a outras pessoas e usada em larga escala, surgem as seguintes questões:

  • De onde emergem as idéias do que será testado?
  • Como posso tornar o processo de geração de idéias mais sistemático, porém preservando a liberdade?
  • Como é possível compartilhar com outros testadores os modelos mentais que geram essas idéias?
  • Como é possível assegurar que aspectos críticos do sistema serão avaliados durante a exploração?
  • Como posso minimizar os fatores humanos durante a exploração (humor, memória, atenção, etc)?

Embora exista uma grande parcela de improviso e intuição no processo de geração de idéias, alguns padrões poderão ser percebidos e mapeados caso sejam adequadamente pesquisados. Cem Kaner em suas pesquisas observando testadores executarem testes exploratórios, identificou que as idéias emergem normalmente de nove possíveis origens (e suas ramificações):

  • Palpites (as idéias são geradas com base na experiência do testador);
  • Modelos (as idéias são geradas a partir de diagramas de arquitetura, tabelas de decisão, etc);
  • Exemplos (as idéias são geradas com base em situações reais de uso do sistema, casos de uso, etc);
  • Interferências (as idéias são geradas para simular a interrupção do fluxo normal de uso do sistema);
  • Invariâncias (as idéias são geradas para a criação de testes que mudam coisas (parâmetros, configurações, etc) que não deveriam causar impacto no funcionamento geral do sistema);
  • Injeção de erros (as idéias são geradas para verificar se o sistema lida adequadamente com situações de erro injetadas);
  • Troubleshooting (as idéias são geradas durante o teste de um defeito que foi corrigido por meio da exploração de situações similares, caminhos alternativos, etc);
  • Idéias proposta por um grupo (as idéias são geradas em grupo por meio de brainstorm, testes em pares, etc);
  • Especificações (as idéias emergem com base na leitura de requisitos, manuais, etc).

No entanto, nos últimos anos o uso de heurísticas tem sido o método comumente usado para compartilhar modelos mentais para a geração de idéias e tomada de decisões. A Wikipédia oferece muitas definições para o termo "heurística", no entanto, a definição que melhor o descreve no contexto do teste exploratório é a seguinte: "A capacidade heurística é uma característica dos humanos, cujo ponto de vista pode ser descrito como a arte de descobrir e inventar ou resolver problemas mediante a criatividade e o pensamento lateral ou pensamento divergente. Geralmente a heurística é aplicada quando um problema é complexo ou traz informações incompletas. No geral, pode ser considerada como um atalho aos processos mentais e, portanto, é uma medida que preserva e conserva os recursos mentais. A heurística funciona efetivamente na maioria das circunstâncias mas também pode conduzir à polarização na tomada de decisão ou no desenvolvimento de julgamentos. O conjunto de soluções heurísticas começa freqüentemente de um raciocínio por analogia. Um exemplo de atalho mental é o uso de estereótipos".

Os especialistas em testes exploratórios frequentemente compartilham suas heurísticas para a geração de idéias por meio de técnicas mnemônicas. Essas técnicas são utilizadas para auxiliar o processo de memorização. Consiste na elaboração de suportes como os esquemas, gráficos, símbolos, palavras ou frases relacionadas com o assunto que se pretende memorizar. Recorrer a esses suportes promove uma rápida associação e permite uma melhor assimilação do conteúdo.

Por meio das heurísticas descritas através de técnicas mnemônicas, os atalhos mentais de testadores experientes podem ser ensinados a outras pessoas de forma sistemática e em larga escala. Muitos autores e especialistas em teste exploratórios compartilham suas heurísticas por meio de livros e artigos. No artigo "How Do You Spell Testing?", James Bach, apresenta uma das heurísticas mais conhecidas na área de testes exploratórios. Neste artigo, Bach descreve a heurística que ele frequentemente utiliza chamada "San Francisco Depot" ou SFDPO. Neste mnemônico, cada letra descreve um atalho mental que nos lembra de cinco categorias do sistema que devem ser investigadas durante a exploração:

  • (S)tructure (O que o produto é): Que arquivos ele usa? Como ele foi construído? São vários ou um único programa? Que tipo de material físico é distribuído com o produto? É possível testar módulo por módulo?;
  • (F)unction (O que o produto faz): Quais são as suas funcionalidades? Que tipo de tratamento de erro o produto realiza? Que tipo de interface ele possui? O produto realiza algum processamento invisível para o usuário? Como o produto se comunica com o sistema operacional?;
  • (D)ata (Quais dados o produto processa): Que tipo de entrada de dados o produto processa? Como é a saída produzida pelo produto? Quais tipos de status o produto pode estar? O produto é distribuído com algum tipo de pré-configuração?;
  • (P)latform (Qual plataforma o produto depende): Qual sistema operacional o produto é compatível? O ambiente e infra-estrutura precisa de alguma configuração especial? O produto depende de algum componente de terceiros?;
  • (O)perations (Como o produto será usado): Quem vai usar o produto? Onde e como o produto será usado? Para que o produto é usado? Existem funções que os usuários usarão com maior freqüência? Existe alguma forma de obter os dados reais do usuário para a criação de testes mais realísticos?.

Em 2005, Michael Bolton publicou no artigo "Testing without a map" outra heurística bastante conhecida pela comunidade de testes exploratórios. A sua representação mnemônicas é "HICCUPPS". Basicamente, esta heurística tem o objetivo de gerar idéias para a validação do comportamento do software com base nas seguintes características:

  • (H)istory: As funcionalidades do software devem se comportar de forma consistente ao longo do tempo;
  • (I)mage: O comportamento e aparência do software está alinhada com a imagem que o fabricante deseja expor ao usuário;
  • (C)omparable products: O software é compatível com software similares;
  • (C)laims: O software se comporta de acordo com os requisitos;
  • (U)ser expectation: As funcionalidades se comportam conforme a expectativa do usuário;
  • (P)roduct itself: As funcionalidades são consistentes entre si;
  • (P)urpose: As funcionalidades atendem o seu propósito;
  • (S)tatuses: O produto está em conformidade, com leis, regulamentos, diretrizes, etc.

Muitos outras heurísticas podem ser encontradas facilmente por meio de pesquisas na Internet. De qualquer forma, é importante destacar que as heurísticas não são verdades absolutas. Elas são guias e diretrizes que dão suporte a tomada de decisão durante a exploração. O testador deverá usar sua experiência, intuição e julgamento para decidir quais heurística podem ser aplicadas. Além disso, os testadores devem ao longo do tempo criar as suas próprias heurísticas com base nas suas experiências pessoais.

Conclusão

Como vimos ao longo do artigo, teste exploratório deixou de ser uma abordagem de teste relegada a segundo plano e de pouca importância para tornar-se uma estratégia viável de testes, especialmente para gerentes de testes que são cobrados por resultados e sofrem pressões para reduzirem cada vez mais o tempo dos ciclos de testes. Se o teste exploratório for conduzido por profissionais experientes, muitos defeitos importantes serão encontrados rapidamente, já que é exigido menos planejamento e preparação (em comparação com estratégias tradicionais de testes).

James Bach no artigo entitulado “Exploratory Testing Explained” recomenda o uso de testes exploratórios quando quiser diversificar os testes e ir além dos testes óbvios. Adicionalmente, testes exploratórios são recomendados nas seguintes situações:

  • Quando se quer ter um feedback rápido sobre um novo produto ou nova funcionalidade;
  • Quando se quer aprender um produto rapidamente;
  • Quando se quer buscar diversidade após executar os testes tradicionais;
  • Quando se quer encontrar defeitos críticos rapidamente;
  • Quando se quer comparar e investigar de forma independente e rápida o trabalho de outro testador;
  • Quando se quer isolar e investigar um defeito;
  • Quando se quer investigar o status de um risco em particular, a fim de avaliar a necessidade de criação de testes tradicionais para mitigar o risco.

POSTS RELACIONADOS

AGENDA

CURSOS RELACIONADOS