Exploratory Testing Tours: Uma “excursão”​ na metáfora do turista

Teste exploratório ainda é um tema muito discutido e estudado. Atualmente vem sendo cada vez mais utilizado em fábricas de testes, até mesmo em projetos ágeis onde o foco são testes de software para entrega contínua. Ao meu ver, o teste exploratório não é uma metodologia de teste. Pelo contrário, é uma abordagem para verificação de qualidade.

Todavia, ainda existem problemas e desafios que fazem os testes exploratórios não serem implementados dentro de um escopo de projeto. São eles:

• Depender da experiência e habilidade do testador;
• Ausência de um plano de testes (falta de visão do que testar e porque);
• Dificuldade de ter visão do progresso dos testadores;
• Dificuldade em casos de reprodução dos testes;
• A limitação dos documentos gerados por testes exploratórios geram falta de informação e dificultam a manutenção do sistema;
• Não é normalmente indicado para sistemas de tempo real

Tendo isso em vista, James A. Whittaker no seu livro exploratory software testing: tips, tricks, tours, and techniques to guide test design (publicado em 2009), lista ferramentas e metodologias a serem associadas aos testes exploratórios com a finalidade de mitigar alguns desses problemas.

Dentre as soluções criadas pelo especialista, está presente o conceito de Tours — uma estratégia que irei focar nesse artigo e mais especificamente na metáfora do turista.

Cem Karner, o precursor do termo Teste Exploratório e um entusiasta do conceito de Tour define:

Tour Testing é uma abordagem estruturada para testes exploratórios, onde a exploração de um produto é organizada em torno de um tema específico

Uma Tour é uma exploração de um produto organizada em torno de um tema. Você decide sobre um tema, depois navega e percorre o aplicativo para documentar as descobertas do tema. As excursões são excelentes para criar uma coleção de ideias, o qual pode ser explorada uma de cada vez, em profundidade. Pense sobre isso como explorar com muito mais detalhes do que se estivesse realizando testes sem estrutura ou orientação.

Vamos usar o exemplo de um turista para explicar algumas coisas. Na metáfora do turista, enquanto realizam testes exploratórios, os testadores se parecem com os turistas que chegam no lugar onde nunca estiveram antes. Os turistas gostariam de visitar e ver o maior número possível de lugares dentro de um prazo limitado. Então, por exemplo, você está visitando Roma pela primeira vez:

• Você pode tentar conhecer a cidade por conta própria;
• Você pode comprar um mapa turístico;
• Você pode contratar um guia;
• Você pode pegar o ônibus de turismo.

No retorno da sua visita você pode:

• Repetir os melhores passeios;
• Escolher visitar novos lugares da cidade.

Utilizando a rotina acima como metáfora, suponha que você está testando agora uma aplicação. O que você usa como guia? Não fique imaginando o aplicativo, sempre tenha um objetivo em mente. Quando apresentado com uma escolha, permita que o objetivo o guie. Rastreie quais metas funcionam para você — cobertura de códigos/features/UI, encontrar falhas importantes, forçar o software a exibir melhor sua funcionalidade.

Cada cidade na metáfora do turista tem vários Distritos. E, com base em seu conforto, os turistas escolhem um ou vários lugares para visitar. Como por exemplo, distritos de negócios ou histórico. Em termos de teste de software, a cidade onde os turistas vão é um produto de software a ser testado. Os distritos são recursos e módulos de software.

Whitakker aponta seis principais distritos com vários passeios disponíveis. Abaixo utilizarei os termos em inglês com a finalidade de manter seu significado original:

Business District

Onde se movimenta o dinheiro. Só há bancos e prédios empresariais e, na maioria dos casos, os turistas não gostam de andar no distrito comercial, pois não há nada interessante para ver.

Um produto de software também tem seus próprios recursos de “Distrito Comercial” que são projetados para aumentar as vendas. O material promocional informa sobre os recursos que diferenciam um produto de software dos similares disponíveis no mercado para atrair mais usuários. Um exemplo seria 30 dias de acesso grátis ao conteúdo de um software após se cadastrar.

Tours desse distrito:

• Guidebook Tour;
• Money Tour;
• Landmark Tour;
• Intellectual Tour;
• FedEx Tour;
• After-Hours Tour;
• Garbage Colletor Tour.

Historic District

Um passeio típico inclui um passeio por bairros antigos repletos de edifícios antigos e locais de valor histórico. Nos testes, um distrito histórico significa os recursos relacionados às versões anteriores do produto, código ou funcionalidade.

Tours desse distrito:

• Bad-Neighborhood Tour;
• Museum Tour;
• Prior Version Tour.

Entertainment District

Depois de uma longa caminhada, os turistas desejam se divertir. Um distrito de entretenimento simboliza a opção de personalização de software. Ele se concentra na funcionalidade relacionada ao core. Os tours podem ajudar a detectar bugs de interface do usuário, erros de localização, problemas de usabilidade e bugs funcionais não críticos.

Tours desse distrito:

• Supporting Actor;
• Back Alley;
• All-Nighter ou Clubbing tours.

Tourist District

Cada cidade tem lugares onde os turistas gastam muito dinheiro. Aqui há muitos restaurantes e lojas de presentes, além de muitas coisas e informações que o turista não conseguem absorver totalmente à primeira vista.

Nos testes, um distrito de turismo significa examinar a funcionalidade do software sem se concentrar em nenhum detalhe

Tours desse distrito:

• Collector Tour;
• Lonely Businessman;
• Supermodel;
• Scottish Pub tour.

Hotel District

Normalmente os turistas ficam em hotéis onde eles podem descansar um pouco e relaxar depois de um dia agitado. Nos testes, um distrito de hotel é um local para verificar a funcionalidade não crítica.

Tours desse distrito:

• Rained-Out Tour;
• Couch Potato Tour.

Seedy District

Um distrito decadente é muito perigoso para os turistas. Nos testes, essas áreas de software atraem usuários mal-humorados que se esforçam para travar o sistema. Os testadores devem se importar com isso e tentar simular as ações de tais usuários.

Tours desse distrito:

• Saboteur tour;
• Obsessive-Compulsive tour;
• Antisocial tour (composto de 3 sub-tour: Opposite, Crime Spree, Wrong Turn).

Toda Tour leva a um destino: o usuário. Muitas vezes, com testes exploratórios, os profissionais ficam absorvidos com a jornada e esquecem tudo sobre o destino.

O usuário final é o beneficiário de todas as técnicas que temos em nosso arsenal, por isso, quando fazemos uma tour, é sempre uma boa ideia manter a visão geral no fundo da mente e refletir sobre as maneiras pelas quais uma tour se inter-relaciona com outras tours e diferentes aspectos do desenvolvimento de software. Na verdade, todas as excursões se mesclam em uma teia gigante de agregação de valor. E se no meio de uma excursão você fizer observações ou formular perguntas relacionadas a outros tipos de passeios, as anote e se certifique de abordá-las mais tarde.

O teste exploratório, se bem utilizado, é um complemento chave em um escopo de projeto de testes. Segundo o princípio nº 2 de testes presente na documentação Syllabus (CTFL): Teste exaustivo é impossível

Testar tudo (todas as combinações de entradas e pré-condições) não é viável, exceto para casos triviais. Em vez do teste exaustivo, riscos e prioridades são levados em consideração para dar foco aos esforços de teste.

E é levando isso em consideração que a metáfora do turista cai como uma luva já que se encaixa perfeitamente como um foco em partes específicas do software sem desperdício de tempo e energia.

Estamos focados cada vez mais em automatização de testes guiados por metodologias ágeis. Porém, ainda existe um receio com relação ao se aplicar testes exploratórios em um ambiente ágil como complemento aos testes automatizados.

Sobre isso, James Whittaker cita em seu livro:

Não há diferença fundamental no projeto de testes automatizados se no desenvolvimento de testes manuais. Ambos exigem princípios semelhantes, sendo a principal diferença a forma como são executados. Princípios deficientes de projeto de teste arruinarão testes manuais e automatizados simplesmente não fazendo nada mais rápido. De fato, eu mantenho que todos os bons testes automatizados começaram suas vidas como testes manuais.

Conclusão

Usar uma Tour é uma maneira simples e lógica de abordar as deficiências mais comuns dos testes exploratórios “puros”. Ou seja, a falta de objetivos e protocolos predefinidos que os testadores novatos consideram particularmente frustrantes e confusos.

Ao realizar a Tour, os testadores podem ter certeza de que cobriram todas as bases de seu trabalho e abordam os testes exploratórios com mais confiança. Eventualmente, quando é hora de mergulhar em testes exploratórios puros, os testadores terão internalizado uma noção melhor do que procurar e como tornar suas viagens pelo software mais proveitosas.

Ainda em tempo, o Tour não é uma alternativa para testes exploratórios não estruturados! Os dois não se excluem. Testes exploratórios não-estruturados ou “puros” trazem uma série de benefícios que os testes de turnê não trazem. O teste de passeio é uma ótima opção para testadores inexperientes. Até mesmo testadores experientes vão querer usá-lo quando o tempo e os recursos de projetos estiverem em falta.

Nesse artigo introduzi conceitos que aprendi enquanto Analista de Testes de Qualidade da Brisa P&D, empresa em que eu trabalhei por sete anos. Fui apresentado ao conceito dos testes baseados em Tours e à metáfora do turista de Whitakker, o que me deixou mais motivado e entusiasmado ao aplicar testes exploratórios em paralelo aos testes que já executávamos. Os resultados eram mais satisfatórios e conclusivos, geravam uma maior curva de aprendizado entre os analistas e relatórios que guiavam tanto futuros testes exploratórios quanto outros testes que se antecipavam a essa fase.