Testes exploratórios

Recentemente no trabalho tive de criar uma apresentação-treinamento sobre teste exploratório. Assim que recebi o pedido pensei: “Ué, mas qual o segredo? Você entra na aplicação, começa a testar o que achar necessário, sem seguir roteiro, sem nada, pra que treinamento sobre isso?”.

Depois comecei a pesquisar sobre o assunto e vi que, se tentarmos resumir a definição, podemos sim usar a minha primeira ideia, mas dessa forma deixaríamos de lado muita informação importante e, eu diria, até essencial sobre testes exploratórios.

Então se você está aqui, você provavelmente não caiu no erro que cometi, definindo sem antes pesquisar. Na sequência do post você pode conferir tópicos interessantes sobre o assunto. ;-)

Definição

O BSTQB (Brazilian Software Testing Qualifications Board) define testes exploratórios como "técnica de modelagem de teste informal na qual o testador controla ativamente a modelagem dos testes já que estes são realizados e utilizam as informações obtidas durante o teste para modelar testes novos e melhores."
Só a definição já elimina meu primeiro pensamento. O testador controla ativamente a modelagem dos testes, ele decide o que vai testar e como vai testar e utiliza o resultado disso para criar novos testes.
Mas quando devemos executar testes exploratórios? Nós executamos o tempo todo, mesmo quando seguimos um script. Se estamos em execução, seguindo um roteiro, ao mesmo tempo estamos prestando atenção em outros detalhes que o roteiro não cita. Nesse caso pensamos: "isso não parece certo?", investigamos e notamos a necessidade ou não de registrar ocorrência ou criar mais testes. Este é um exemplo simples, mas recorrente no nosso dia-a-dia. Também podemos separar um tempo só para isso: “Hoje vou ficar 30 minutos navegando na aplicação livremente, sem roteiro” e ainda assim encontraremos defeitos que não encontraríamos em testes com script.

Vantagens

- Você executa ações no sistema que não estão previstas em scripts, você tenta caminhos "impensáveis";
- Pode aumentar o número de defeitos encontrados na aplicação;
- Aumenta o conhecimento sobre a aplicação.
O segundo e o último itens talvez sejam os mais importantes.
Aumentar o número de defeitos encontrados dispensa explicação e isso é claramente benéfico para a equipe de testes. O último talvez seja a forma mais rápida de introduzir alguma aplicação sem necessidade de longos treinamentos e longas leituras de requisitos. Quem nunca ficou com tempo livre no começo do projeto e começou a "brincar" na aplicação? Esse "brincar" tem mais importância do que parece e, no final, adquirimos conhecimento essencial sobre a aplicação em teste sem a necessidade de lermos dezenas de documentos.

Acho que isso já é suficiente para conhecermos um pouco mais do assunto, eu poderia me estender e comentar alguns artigos, mas acho mais válido ler os artigos originais.

Abaixo temos alguns artigos muito bons sobre o assunto:

http://www.satisfice.com/articles/et-article.pdf
http://www.quardev.com/content/whitepapers/ExploratoryTestingasSport_JonBach_PNSQC06pdf.pdf
- Sobre o autor do artigo: James Bach - http://www.satisfice.com/aboutjames.shtml

http://www.kaner.com/pdfs/ETatQAI.pdf
- Sobre o autor do artigo: Cem Kaner - http://en.wikipedia.org/wiki/Cem_Kaner