Representando testes ágeis

Vários membros da comunidade Agile têm explorado estilos para o registro ou declaração de testes. Charles Bradley descreve várias formas de expressar os testes de uma história, resumidos a seguir, começando com maneiras muito simples e aumentando gradualmente a sofisticação.

• Com marcadores – Escrever o comportamento do sistema real e o esperado como uma série de marcadores, em um cartão de história de usuário ou em uma página wiki. Esta técnica é útil para histórias pequenas ou simples.
• "Testar com..." – Registrar quaisquer cenários ou dados necessários para executar os testes. Por exemplo, "Testar a senha atual com entradas incorretas, corretas e vazia." De maneira similiar ao uso de marcadores, essa técnica funciona melhor com histórias mais curtas.
• "Testar que..." – Começar com "Testar que...", seguido pela sequência que deve ser verificada no comportamento do sistema. Este é um dos estilos mais simples para registro de testes, e pode funcionar bem para testes que não são bem representados usando os estilos anteriores.
• Estrutura "Dado que/Quando/Então" – Usar três seções com títulos "Dado que", "Quando" e "Então". Na seção "Dado que", relacionar as condições prévias, premissas, a configuração inicial do teste, dados de entrada e o estado do sistema antes do teste. Na seção "Quando" incluir a ação inicial ou o evento de transição de estado. E em "Então", descrever o comportamento do sistema, a saída esperada e/ou o próximo estado do sistema. Este estilo funciona bem para testes que exigem muitas pré-condições ou que têm ações iniciais específicas.
• Especificação através de exemplos: forma conceitual – Criar uma tabela de dados de entrada de testes e os resultados esperados e descrever conceitualmente os dados, ao invés de usar valores específicos. Testes que podem ser facilmente organizados em formato de tabela se beneficiarão muito do uso deste método.
• Combinações – Um estilo que combina vários dos estilos e métodos acima, para melhor atender a diversos aspectos de testes mais sofisticados.

Peter Stevens descreve outra forma para o registro de testes, que chama de "Como demonstrar". Trata-se essencialmente de um fluxo de atividades simples que descreve como fazer a demonstração de uma história completa para o Product Owner. Ele escreve:

A criação do "Como demonstrar" faz parte do refinamento do backlog do produto. Portanto, pode ser feita tanto na reunião de estimativa/release, ou no primeiro planejamento de sprint, ou ainda em algum momento intermediário. Faz parte da Conversação, por isso não deve acontecer com muita antecedência.

Lisa Crispin descreve o uso de um mapa mental (mindmap) para planejar testes necessários para concluir um tema completo. O tema descrito por ela precisou de cinco sprints para ser concluído, representando dez semanas de trabalho. Crispin e um engenheiro de testes começaram por desenhar em um quadro branco um mapa mental do teste a ser realizado. Discutiram, em seguida, o mapa com a equipe de desenvolvimento, o Product Owner, o controlador e outras partes interessadas.

Segundo Lisa, os testadores se referiram muitas vezes ao mapa mental durante o desenvolvimento do tema:

Ao final, nos sentimos confiantes de termos pensado e discutido todos os ângulos do processo, seus potenciais impactos em outras partes do sistema, além de ter conversado com todos os interessados ​​sobre suas necessidades e preocupações, e feito um conjunto de testes adequado, não só no nível funcional, mas também com relação ao desempenho e à usabilidade.

Como você realiza a declaração de testes na sua equipe?