Fugir do tema nunca
foi opção, vez ou outra você acabará encontrando as palavras
"Teste Exploratório" no seu cotidiano. E saber que ele é
bem diferente do tal "testa aí" se faz necessário até
mesmo para que você perca seus pré - conceitos sobre o tema.
Vejamos alguns
conceitos associados ao Teste Exploratório:
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".
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 ideias 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.
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".
E como são as
atividades desse tal de Teste Exploratório?
Lee Copeland, no
seu livro "A Practitioner"s Guide to Software Test Design
definil um possível processo a ser seguido durante a execução do
teste exploratório:
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).
Mas como eu crio uma
hipótese?
James Bach usa o
seguinte mnemônico para ajudar a criar hipóteses para seus testes
exploratórios:
(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?.
Já Michael Bolton
usa o seguinte:
(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.
Tá, entendi como
criar as hipótese e prosseguir com os testes. Mas quando seu uso é
indicado?
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.
Para maiores
informações leia uma "mesa redonda" que rolou no grupo
DFTestes:
https://qualidadebr.wordpress.com/2010/03/14/testes-exploratorios/
Bibliografia:
CAETANO, Cristiano.
TESTES EXPLORATÓRIOS (PARTE 1): INTRODUÇÃO. In: Qualister.com.br,
Abril/2016.
Disponível em
.
