Um dos assuntos mais controversos na área de teste, sem dúvidas, é o caso de teste. Devemos escrevê-lo com qual nível de detalhes? com qual profundidade? um para cada função? um para cada fluxo? end to end? etc.
Principalmente para quem está começando com o teste de software, existem diversas dúvidas. Por muitas vezes essas dúvidas aparecem mesmo com relativa experiência.
Especialmente em ambientes ágeis, esse quesito é um desafio diário. Existe ainda quem acredite que em equipes ágeis essa necessidade (tanto como boa parte da documentação) é suprida somente pela comunicação.
Mas, isso é realmente verdade?
Leia o manifesto ágil aqui: http://www.manifestoagil.com.br/
E observe que, apesar de priorizar comunicação ao invés de documentação, isso não quer dizer, em momento algum que iremos deixar de fazer documentação!
Pense comigo o seguinte cenário: o produto está em produção, e uma nova função foi desenvolvida as pressas (como geralmente ocorre com um produto que já está em produção). Nessa correria os analistas alegam que não tiveram tempo de detalhar em documentos como a função deve ser. Se o analista já for o próprio desenvolvedor então (como acontece em empresas pequenas, onde o acúmulo de função é comum), aí há grandes chances de ele ter ido direto dos requisitos ouvidos dos stakeholders para o desenvolvimento da função.
Em um mundo ideal, não deveria acontecer o fato de se passar de um reunião direto para o desenvolvedor, nem tão pouco o acúmulo de função. Deveria existir um registro que detalhasse como a função deve ser. Porém, entendemos que muitas vezes “no mundo real” as pressões sofridas para a entrega levam ao pulo desse passo. Na correria pela entrega de uma determinada função, em geral, a documentação é sacrificada.
Continuando o pensamento, a função foi desenvolvida sem (ou com pouca, insuficiente) documentação. Tudo corre bem, até que ela chegue para o teste. Chegando em teste, a primeira pergunta que nós de teste fazemos é:
E o que essa função deve fazer? (o “deve fazer” inclui múltiplas subperguntas, quais regras/fluxos/papeis deve obedecer? dentre outras).
Se houver documentação, isso será o perfeito auxílio para se originar os requisitos de teste, e então montar os casos de teste.
Mas e se não tiver a documentação?
É aí que os pontos do manifesto ágil são chave para o sucesso. Proximidade e comunicação irão diminuir o problema da falta de documentação, mas por vezes as memórias falham e as pessoas esquecem detalhes do que foi combinado. Então, mesmo que seja relativamente fácil se comunicar com a equipe e “relembrar” o que foi acordado, o ideal é que isso esteja documentado em algum lugar de alguma forma.
Para se testar qualquer função que seja, é necessário a correta definição de como ela deveria se comportar. O fato, é que venha de onde vier, para que o teste seja bem realizado, essas informações devem ser obtidas. Nem que seja conversando com os analistas/desenvolvedores para entender melhor como ela foi feita.
Porém, essa reunião de informações que o pessoal do teste terá de fazer, demanda tempo e esforços que poderiam ser “economizados” caso uma boa documentação tivesse sido realizada. O que é uma boa documentação, vai variar de lugar para lugar. Como praticamente tudo na engenharia de software, o bom é o que é adequado (funciona, agrega valor, auxilia) a realidade em que se trabalha.
Aí tudo bem, você gastou um tempão para reunir as informações sobre determinada função. Agora o que você faz com isso? a menos que tenha uma memória de elefante (o que não é muito comum para o pessoal da nossa área) seria interessante anotar, organizar, estruturar e armazenar essa informação de alguma forma.
E é aí que o caso de teste se torna um poderoso aliado!
O caso de teste nada mais é do que um conjunto de informações que serão fornecidas para o produto sobre teste juntamente com as saídas esperadas desse produto.
Um grande possibilidade de documentação dos casos de teste, bastante utilizada nos contextos ágeis são os cenários de uso que fazem parte das histórias de usuário (user stories) que eu falo nesse texto aqui. Esse formato é muito utilizado e ajuda muito na automação dos testes. Tenho um vídeo falando sobre BDD aqui>
Uma outra possibilidade é escrever os casos de teste em uma Wiki que seja compartilhada entre os membros da equipe. Algumas ferramentas de teste automatizado também utilizam esse formato para executar os testes.
Uma outra possibilidade ainda é um documento de texto versionado no SVN ou GIT, Google Docs, ou qualquer outra coisa assim também.
O que não vale é deixar de criar os casos de teste e com isso perder o controle dos testes executados, e também dos cenários que se pretende exercitar.
Conclusão
Ao se testar algo, é importantíssimo criar casos de teste, nem que seja em um formato simples, mas que o auxilie a organizar as ideias do que deve ser testado.
Como o caso de teste será feito é uma decisão da equipe, respeitando o que faz sentido e agrega valor para a equipe e empresa. A granularidade (detalhamento, profundidade) vai depender de cada situação.
