Teste Exploratório no Contexto Ágil

Um guia para usar teste exploratório em equipes de desenvolvimento ágil.

Texto de: Elisabeth Hendrickson
Traduzido por: Graziela Rustiguella Franzoni

Afinal, o que é teste exploratório?

Teste exploratório envolve aprender sobre o software em teste e executar testes simultaneamente, usando feedback do último teste para informar o próximo.

Cem Kaner cunhou o termo na década de 1980, embora a prática, sem dúvida, começou muito antes.

Há um mal-entendido de que o teste exploratório significa simplesmente “fazer as coisas aleatórias e ver o que acontece”, é importante enfatizar que essa é uma prática investigativa rigorosa. Nós usamos o mesmo tipo de técnicas de análise que usamos no projeto tradicional, mas executamos o teste imediatamente. O projeto e a execução do teste tornam inseparáveis, uma única atividade.

Teste como experimento

Quando planejamos testes enquanto exploramos, temos uma hipótese sobre como o software se comportará: talvez suspeitamos que o software apresentará um determinado tipo de erro, ou talvez estejamos confirmando como o software funciona.

De qualquer forma, pensamos em um pequeno experimento e o executamos imediatamente. Nossos experimentos nos ensinam sobre o sistema. Aprendemos como funciona, o que faz funcionar, como é organizado. Descobrimos não apenas o que funciona e o que não funciona, mas também padrões gerais de vulnerabilidades.

Quanto mais aprendemos sobre como o sistema funciona e as circunstâncias sob as quais ele se comporta mal, melhor somos em planejar bons casos de testes que produzem informações úteis.

Sério? Não bate em nenhum teclado?

Às vezes fazemos coisas ao explorar que parecem estranhas para um observador externo.

James Bach fala sobre seu “Teste do Sapato” no qual ele coloca um sapato no teclado. Mas James não coloca um sapato no teclado porque ele está tentando criar coisas aleatórias malucas. Ele faz isso porque notou que alguns softwares apresentam mau comportamento quando recebem muitas entradas de chave ao mesmo tempo. Colocar um gato no teclado ou entregá-lo a uma criança de 2 anos pode resultar em comportamento semelhante. Mas um sapato ou um livro costuma ser mais prático.

Então, sim, pode haver batidas de teclado envolvidas no Teste Exploratório. Mas é o teclado batendo com uma teoria de erro potencial, não apenas coisas malucas aleatórias porque não podemos pensar em nada melhor para fazer.

Teste exploratório e ágil

O teste exploratório é uma prática de teste para equipes ágeis.

Em um contexto ágil, os testes de regressão com script são normalmente automatizados. O sistema de Integração Contínua (CI) executa esses testes em cada compilação. Essa automação é essencial para obter o feedback rápido que as equipes ágeis precisam fornecer com frequência em um ritmo sustentável.

No entanto, toda essa automação não é suficiente para garantir que o
sistema faz tudo o que esperamos e nada que não fazemos. Alguém,
em algum lugar, tem que realmente usar o sistema.

E, no entanto, escrever scripts de teste detalhados para um esforço de teste manual não faz sentido em um contexto ágil. Se for um teste importante o suficiente para criar scripts e executar repetidamente, é importante o suficiente para automatizar.¹

Portanto, as equipes ágeis ainda precisam de testes manuais, mas não precisam de testes repetitivos seguindo um script. Em vez disso, as equipes ágeis precisam de uma abordagem de teste manual que seja adaptável (porque o software em teste muda muito rapidamente em projetos ágeis) e que produz grandes quantidades de informações rapidamente (porque as equipes ágeis prosperam com feedback rápido).

O teste exploratório é um ajuste perfeito!

Em vez de documentar instruções passo a passo, capturamos apenas declarações simples que representam perguntas que queremos que o teste seja capaz de responder.

Em seguida, usando cartas para focar nossas explorações e heurísticas para nos guiar, percorremos o software rapidamente, cutucando e cutucando para revelar consequências não intencionais de decisões de design e riscos que não consideramos antecipadamente. Ao fazer isso, coletamos grandes quantidades de informações muito rapidamente.

Além disso, como o Teste Exploratório envolve o uso dos resultados do último teste para informar o próximo, podemos adaptar nossa abordagem de teste rapidamente se notarmos algo que possa indicar uma vulnerabilidade ou risco. Podemos adaptar nossas investigações ao que é importante agora, sem sermos obrigados a seguir um roteiro de teste que achamos importante alguns meses atrás.

Este artigo cobre os elementos essenciais do Teste Exploratório:
aprender o sistema de fora para dentro; projetar testes usando
heurísticas; executar testes e observar os resultados de perto; e
integrando Testes Exploratórios no desenvolvimento de histórias dentro de um Sprint ou Iteração.

¹ Discutir estratégias de automação está fora do escopo deste livro. Mas sim, acho que se você puder escrever um script manual para um teste, poderá automatizá-lo. Se você puder fornecer instruções passo a passo repetíveis para um humano para executar um teste, poderá escrever um teste automatizado para fazer a mesma coisa. E se você vai argumentar “mas você não pode escrever software para desconectar um cabo de rede”, vou dizer que você pode. Ou, mais especificamente, os programadores que escrevem a lógica de tratamento de erros de rede podem tornar isso possível escrevendo o código de modo que um simulador possa fingir puxando o cabo de rede. Você ainda precisará fazer a exploração manual, é claro, mas ter um pequeno número de testes de regressão automatizados repetíveis em torno da desconexão do cabo de rede salvará a equipe de um mundo de sofrimento no dia em que alguém verificar acidentalmente o código que interrompe esse tratamento de erros.

Aprendendo

Aqui discutimos o aprendizado sobre o sistema e a captura do nosso entendimento para uso posterior no projeto de testes.

Cenários simples

O que o software pretende fazer?

É aqui que você começa a aprender sobre o sistema: com o caso mais simples que deve funcionar. Você ainda não está testando o software, mas está testando sua compreensão.

Você está explorando um carrinho de compras? Adicione um item. Verificação de saída. Testando um processador de texto? Escreva algum texto. Adicione uma imagem. Salve isso. Testando um servidor DNS? Consulte-o para obter um endereço IP para um domínio. Seja o que for que você está testando, comece fazendo ações básicas do usuário para ver o que o sistema faz.

À medida que avança, comece a tomar notas sobre…

Substantivos e verbos

Os substantivos do sistema são as coisas que ele manipula,
gerencia e interage. Substantivos típicos para um carrinho de compras incluem coisas como: carrinhos, usuários registrados, itens, quantidades, preços, descontos, cupons, métodos de pagamento e endereços.

Os verbos do sistema são as ações que você pode realizar usando o
sistema, ou que o sistema pode tomar. No exemplo do carrinho de compras, os verbos podem incluir: conferir, atualizar, excluir, abandonar, salvar, conectar, desconectar.

Ao coletar uma lista de substantivos e verbos para o sistema, você está capturando uma linguagem que descreve o sistema. Será
útil para projetar testes, bem como para futuras explorações para
aprender mais sobre a forma do sistema.

Caminhos alternativos

Ao explorar o sistema notando substantivos e verbos, é provável que você perceba que há mais de uma maneira de fazer as coisas.

Talvez você possa fazer login abrindo uma página de login e também
preenchendo suas informações de login nos campos de nome de usuário/senha que aparecem no topo de cada página. Talvez haja uma opção “lembrar de mim” que permite que o sistema mantenha você conectado por dias ou semanas.

Talvez você possa excluir um item do carrinho de compras alterando
a quantidade para 0, ou clicando em um botão Excluir, ou esvaziando
seu carrinho de compras.

Sempre que você perceber que existem várias maneiras de chegar ao mesmo resultado, anote. Você vai querer variar esses caminhos à medida que explora.

Diagrama de contexto

O software vive dentro de um ecossistema inteiro. Ele é executado em um sistema operacional, armazena dados no sistema de arquivos ou em um banco de dados e se integra a outros softwares, como gateways de pagamento para processamento de cartão de crédito, servidores SMTP para e-mail e sistemas internos como relatórios de vendas, controle de estoque e warehouse/ aplicações de envio.

Ao começar a explorar, crie um diagrama de contexto simples que mostre recursos ou dependências externas, como o da esquerda. Com o tempo, quando você aprender mais sobre o sistema e o contexto em que ele vive, adicione mais detalhes.

Cada sistema dependente oferece oportunidades adicionais para
exploração.

Variáveis

Se você é um programador, uma variável é um local nomeado na memória. Você declara variáveis com instruções como “int foo;”

Não é desse tipo de variável que estamos falando aqui.

Em vez disso, estamos falando de “variável” no sentido de “coisas que você pode variar”. Mais especificamente, uma variável em teste é qualquer coisa que você pode alterar, ou fazer com que seja alterado, por meio de interfaces externas (como a interface do usuário ou o sistema de arquivos), que podem afetar o comportamento do sistema.

Às vezes, as variáveis são coisas obviamente mutáveis, como o valor em um campo em um formulário. Às vezes, eles são óbvios, mas não devem ser alterados diretamente, como os pares de chave/valor em uma string de URL para um aplicativo baseado na web. Às vezes, são coisas sutis que só podem ser controladas indiretamente, como o número de usuários logados em um determinado momento ou o número de resultados retornados por uma pesquisa.

Variáveis sutis são aquelas que muitas vezes perdemos ao analisar o
software para projetar testes. Considere, por exemplo, o caso Therac-25 que Nancy Leveson descreve em seu livro Safeware.

O Therac-25 era uma máquina de radioterapia que deu uma overdose de radiação em pacientes, matando-os. A história remonta à década de 1980, mas ainda é relevante hoje.

De acordo com Nancy Leveson, em pelo menos um caso, o mau funcionamento que causou a morte pode ser rastreado até o médico.
Inserir e editar os dados de tratamento em menos de 8 segundos.
Esse é o tempo que as travas magnéticas demoram para engatar. Observe duas variáveis sutis importantes, ou coisas que um usuário pode alterar: a velocidade de entrada e a sequência de ações.

Além disso, Leveson descobriu que a cada 256 vezes que a rotina de configuração era executada, ela ignorava uma importante verificação de segurança. Essa é outra variável sutil: o número de vezes que a rotina de configuração foi executada.

À medida que você começa a aprender o sistema, anote as coisas que você percebe que pode mudar, ou causar mudanças, que são sutis ou interessantes.

Quanto mais você procurar por variáveis, mais você encontrará. Eles estão em todos os lugares.

Então, conforme você explora, use a heurística descrita nos Casos de Testes para sugerir variações interessantes.

Casos de testes

Discutiremos o uso de heurísticas para casos de testes em tempo real.

Usando heurísticas

Você começou a explorar o sistema. Você tem a forma dele. Você entende o contexto em que vive, o tipo de dados que manipula, as ações que você pode tomar. Você pode ter algumas ideias sobre sequências e configurações que podem ser interessantes.

Esta seção apresenta uma seleção de heurísticas: ideias de teste que são gerais o suficiente para serem aplicáveis em uma ampla variedade de domínios e tecnologias.

Use esta seção como referência quando você ficar sem novas ideias para experimentar.

[nota: cada heurística terá cerca de uma página de explicação/
exemplos.]

Interações do sistema de arquivos
Variações de rede
CRUD: criar, ler, atualizar, excluir
Posição: Começo, Meio, Fim
Contagem: 0, 1, muitos
Interrupções
Estados e Transições
Tempo: Antes, Durante, Depois
Combinando heurísticas
Randomizando combinações de substantivos e verbos
Seguindo os dados
Personas

Mecânica

Discutiremos como estruturar suas explorações dentro de um Sprint ou Iteração em um processo ágil.

Cards

O teste tradicional com script é centrado na documentação com
Planos de Teste, Estratégias de Teste, Casos de Teste e Procedimentos de Teste.

O Teste Exploratório envolve muito menos documentação. Nós não
documentamos cada caso de teste. Em vez disso, escrevemos cartas:
declarações simples das informações que esperamos descobrir
através da exploração.

Uma maneira de expressar cartas é com o modelo simples:

Explorar área
Com recursos, restrições, ferramentas, etc.
Para descobrir informações

Algumas cards são amplos:

“Explore o sistema com uso típico cenários para descobrir como funciona.”

Alguns são limitados:

“Explore o recurso de importação de arquivo com vários formatos de arquivo inválidos para descobrir se há alguma circunstância em que o tratamento de erros não fornece uma resposta razoável a um arquivo inválido”.

Alguns são sobre cenários de uso válidos com personas de usuário representativas:

“Explore a navegação e as compras com uma perspectiva de usuário não técnico para descobrir como é fácil ou difícil comprar itens”.

Outros são sobre cenários de uso indevido:

“Explore o recurso de carrinho de compras com uma ferramenta para realizar solicitações HTTP POST para descobrir se há alguma maneira de obter coisas de graça”.

Podemos expressar as cartas de maneira um pouco diferente, e tudo bem. O objetivo da carta é fornecer um foco para nossas explorações.

Sessões

Durante uma sessão, se percebermos que estamos saindo pela tangente, usamos a carta para nos lembrar o que devemos investigar. Podemos anotar outra carta para investigar mais tarde, mas fazemos questão de permanecer na carta por enquanto.

Referências

Bach, James. “What Is Exploratory Testing?”

Bach, Jonathan. “Session-Based Test Management”

Kohl, Jonathan. “Exploratory Testing on Agile Teams”

Kohl, Jonathan, “User Profiles and Exploratory Testing”

Marick, Brian. “A Survey of Exploratory Testing”

Tinkham, Andy and Kaner, Cem. “Exploring Exploratory Testing”

Discutimos o aprendizado sobre o sistema e a captura de nosso entendimento para uso posterior no projeto de testes.