3 coisas a serem consideradas nos seus testes exploratórios

Publicado por Lindomar Reitz no dia qa

Testes exploratórios

Atualmente muito se fala sobre testes automatizados, principalmente em times que utilizam metodologias ágeis. Ainda assim, mesmo com uma grande quantidade desse tipo de testes, os testes manuais ainda possuem o seu valor, sendo que a abordagem de testes exploratórios ganhou bastante popularidade nos últimos tempos, sendo um dos motivos o maior entendimento e prática do agile testing.

Mas antes de aprofundar nessa discussão, uma definição de testes exploratórios precisa ser estabelecida.

O que são testes exploratórios?

Existem várias definições sobre esse tipo de teste, mas uma das mais simples e objetiva é a do James Bach que diz que: “É um processo simultâneo entre aprendizado, especificação e execução de testes.”.

Nesse sentido, esse tipo de teste sugere que você deveria gastar mais tempo executando os testes do que planejando, sendo também uma forma de encontrar outros tipos de problemas que possam passar despercebidos em outras etapas do desenvolvimento. Além disso, a pessoa que está fazendo o teste exploratório decide o que fazer a cada ação ao invés de seguir passos pré definidos, o que ajuda em aumentar a variação de cenários de teste.

Mesmo com essa liberdade de decidir o que e onde testar, ao menos uma estrutura básica deve ser feita, o que será explicado a seguir.

1. Estrutura do teste

Existem vários pontos que podem ser definidos em uma estrutura de testes exploratórios e que pode variar de empresa para empresa. Uma sugestão seriam os seguintes pontos:

Missão: Um título que descreve (sem precisar de muitos detalhes) o que será testado dentro de um timebox.

Recursos: Definir em qual ambiente será testado e se é necessário algum Setup (registros no banco de dados, acesso a outros serviços, etc.).

Timebox: Um tempo limite para a execução dos testes. Isso é um ponto importante para se ter foco em cumprir o escopo da missão, sem distrações.

Problemas encontrados: Descrição rápida e sucinta de problemas encontrados. Vale mencionar que podem ser bugs, problemas de UX, dúvidas, entre outros pontos que forem relevantes de citar na sessão de teste.

Observações: Qualquer informação relevante que possa gerar ideias para novos testes ou comentar sobre o que foi encontrado na sessão.

2. Escopo da missão

Dada a importância de ter uma boa missão de testes, existem alguns problemas na definição do seu escopo, sendo estes problemas explicados a seguir:

Missões muito específicas

Um exemplo de missão específica pode ser vista na figura 1:

Missão muito específica

Figura 1: Exemplo de missão muito específica (Hendrickson, 2013)

Nesse exemplo de missão, o escopo do teste está específico em algumas condições de um campo de texto, o que não justificaria em fazer uma sessão de testes para isso, dado que teria muito pouco a explorar nessa situação.

Missões muito abrangentes

Em contrapartida, uma missão muito abrangente também pode trazer problemas, como mostra a figura 2:

Missão muito abrangente

Figura 2: Exemplo de missão muito abrangente (Hendrickson, 2013)

Nesse caso, ter uma missão que se procura avaliar todos os tipos de problemas, ou, por exemplo, fazer o teste em um sistema inteiro é algo que dificilmente será atingido em um timebox (30 minutos, 1 hora ou 1 dia). Com esse escopo, o foco será difícil de ser mantido, o que prejudica a sua eficiência.

Missões mais objetivas

Um exemplo de missões mais objetivas é mostrada na figura 3:

Missões mais objetivas

Figura 3: Exemplos de missões mais objetivas (Hendrickson, 2013)

Nesses exemplos, as missões estão mais objetivas, mas ao mesmo tempo oferecem liberdade nas decisões de quem vai fazer o teste. Para esses casos, a missão tem que ser pensada para caber em um timebox, independente do tempo que seja.

3. Heurísticas

Para aumentar a variação e gerar novas ideias nos testes exploratórios, o uso de heurísticas são interessantes de aplicar. Apesar de existirem vários tipos, uma analogia proposta por James Whittaker em seu livro “Exploratory Software Testing” é o de pensar que o seu sistema seja igual a uma cidade turística: você tem vários lugares para visitar, assim como tem vários caminhos a seguir dentro dessa cidade. Com isso, esse autor propôs um conjunto de heurísticas que são “tours” dentro da cidade (ou em nosso caso, um sistema). Alguns desses tours são exemplificados a seguir:

Money Tour

Essa heurística é mais focada em explorar as funcionalidades principais do sistema, ou seja, aquelas que fazem que o usuário pague pelo seu produto. Apesar de existirem outras funcionalidades, o foco é manter nesses fluxos principais para encontrar problemas e inconsistências.

Back Alley Tour

É o oposto do Money Tour, sendo que basicamente são explorados as áreas menos utilizadas do sistema, como, por exemplo, opções de configurações. Uma área pouco utilizada também pode ser uma fonte interessante para se encontrar problemas.

Landmark Tour

Útil quando alguma área do sistema tem algum passo pré definido para ser feito. A ideia desse tour é o de trocar a ordem de como as coisas são feitas, aumentando a variação de possibilidades e saindo do caminho “feliz” uma funcionalidade ou o que um conjunto delas sugere a ser feito.

Intellectual Tour

Esse tour busca encontrar problemas nos casos que você faça o sistema “pensar”, como, por exemplo, quando se faz um filtro que retorna muitos resultados ou algum outro processamento mais pesado. Também é uma opção interessante para ver como o sistema se comporta com muitos dados.

Obsessive-Compulsive Tour

Como o nome do tour sugere, o foco é tentar simular os casos em que usuários são obsessivos/compulsivos, como, por exemplo, quando se preenche algum campo muito rápido ou quando se tem a mania de clicar várias vezes em um mesmo botão. Esse tour é interessante para pegar esses tipos de problemas que em um primeiro momento podem não ter sido pensados.

Vantagens

Algumas das vantagens para esse tipo de teste são:

  • Úteis quando existe pouca ou nenhuma documentação;
  • Ajudam a cobrir outras situações (aumentam a variação);
  • Geram novas ideias para os testes;
  • Incentivam o pensamento crítico.

Desvantagens

Como desvantagens para aplicar testes exploratórios são:

  • A sua eficiência depende da experiência/habilidade;
  • Necessitam de certa experiência no domínio;
  • Não devem ser levados como principal abordagem de teste.

Conclusão

Testes exploratórios são uma opção interessante para encontrar problemas que até então poderiam passar despercebidos, além de aumentar a criatividade e pensamento crítico de quem vai fazer o teste. Mesmo com essa liberdade, um mínimo de estrutura e planejamento deve ser feito, para ter mais foco e eficiência ao executar uma sessão de teste.

Vale mencionar que eles não devem ser levados como a principal abordagem de testes, mas sim de forma complementar, junto com os testes automatizados e com o planejamento de cenários de teste para ter uma maior cobertura. Um exemplo de como fazemos isso na Resultados Digitais é no processo de solução, sendo descrito pela Ana Paula em seu post Como inserir o QA no processo de solução.

E você, já aplicou testes exploratórios em algum contexto? Se sim, quais foram os benefícios e limitações que você observou?

Leituras recomendadas:

Lindomar Reitz

Lindomar Reitz

Quality Assurance

Comentários