Tenha sucesso com seus testes elaborando cenários e casos de teste corretamente

Quando se trata de testes de software, com certeza você já deve ter ouvido algumas expressões como, cenários de teste, critérios de aceitação, Gherkin, etc. À medida que o mercado de testes cresce, novas terminologias são criadas, e é importante que tenhamos conhecimento sobre cada uma delas e seu significado, para que possamos usá-las de forma correta no dia-a-dia. A ideia desse artigo é esclarecer as diferenças entre Plano, Cenário, Condição e Caso de Teste. Provavelmente você já utilizou esses termos inclusive como sinônimos, mas será que são sinônimos mesmo? Para garantir a qualidade de um teste, precisamos que ele seja adequado e que realmente represente os casos de uso daquilo que está sendo testado, garantindo um funcionamento robusto. E para termos bons testes, precisamos primeiro ter um bom planejamento. E para um bom planejamento, precisamos conhecer e entender os conceitos básicos.

Vamos começar então pelo Plano de Testes. Quando se tem um projeto sendo executado, seja ele um software, um hardware, um estudo, ou qualquer outro tipo de projeto, vários documentos são produzidos para planejar aquele projeto. E um desses documentos é o Plano de Testes. Ele vai descrever qual será a estratégia de teste, o que deverá ser testado, quem deverá testar, como deverá testar e com quais ferramentas. No contexto ágil e de desenvolvimento de software, o Plano de Testes em sua totalidade não é utilizado com muita frequência, por ser uma documentação extensa e burocrática. Mas ele pode ser utilizado numa versão simplificada, como um documento que reúne todos os cenários de testes de um projeto. Dessa forma, o objetivo dele é ser um documento que mapeia como será feito o processo de testes que garantirá o valor e a qualidade da entrega para o cliente.

Um Cenário de Teste, por sua vez, é uma ideia do que deve ser testado. E aqui vale ressaltar que o termo Cenário de Teste foi recentemente criado pelo mercado, e é um sinônimo para uma Condição de Teste. Então, dado um projeto, que tem um funcionamento bem definido, os cenários de teste devem descrever os funcionamentos e situações que devem ser testados, a fim de identificar se o resultado é o esperado. E como fazer essa descrição da ideia? Imagine que estamos testando um sistema de banco, um exemplo de cenário de teste que podemos ter é: Testar que feito um depósito em conta, o dinheiro estará disponível no tempo estipulado. Ou ainda: Testar que o cartão vinculado à conta é capaz de sacar dinheiro. Percebam que o cenário possui uma descrição apenas, e essa descrição deve conter qual funcionalidade devemos testar e o que é esperado dela.

Vamos definir agora o Caso de Teste. Este é um conjunto de valores de entrada, pré-condições de execução, dados de entradas, resultados esperados e pós condições de execução, desenvolvido para uma condição ou cenário de teste. Isso significa então, que quem elabora como o teste deve ser feito é o caso de teste. E um cenário ou condição de teste pode possuir uma série de casos de teste. Então para o cenário de teste, “Testar que feito um depósito em conta, o dinheiro estará disponível no tempo estipulado”, podemos ter os seguintes casos de teste:

Caso 1:

• Pré-condição: O depósito em conta deve estar funcional
• Entradas: Fazer um depósito de R$ 100
• Resultado esperado: A conta deve ter o valor anterior mais os R$ 100 depositados após 24 horas
• Pós-condição: Os R$ 100 devem permanecer na conta no dia seguinte

Caso 2:

• Pré-condição: O depósito em conta deve estar funcional
• Entradas: Um depósito de R$ 100 deve ter sido feito há 4 horas
• Resultado esperado: O valor de R$ 100 deve ser exibido na conta como lançamento futuro
• Pós-condição: -

Podemos representar todos esses conceitos no seguinte diagrama:

Agora que sabemos tudo que compõe uma estratégia de teste, podemos introduzir o conceito de Critérios de Aceitação. Esses critérios são especificados em uma User Story, e tem o intuito de descrever o comportamento esperado daquela funcionalidade que está sendo pedida, além de delimitar os limites da entrega descrita naquela estória.

E qual a relação dos critérios de aceitação com os cenários e casos de teste? Os critérios de aceitação podem e devem ser um inspirador para a definição dos cenários de testes que devem ser validados. No entanto, eles não representam todos os cenários. Para extrair esses cenários utilizamos técnicas de teste que nos auxiliam a definir os funcionamentos que devem ser validados, bem como casos de borda, casos de performance variada, casos de comportamento inesperado etc.

Gherkin

Gherkin e Cucumber são palavrinhas bem conhecidas no mercado de Qualidade de Software. Sendo Cucumber, uma ferramenta que lê instruções que são executáveis e ​​escritas em formato de texto simples, e valida se o software faz o que essas especificações dizem. Já Gherkin é um conjunto de regras gramaticais, que torna o texto simples, estruturado o suficiente para o Cucumber entender. Dessa forma, o formato do Gherkin realmente facilita a escrita de testes automatizados. Mas será que um teste em Gherkin representa um cenário ou um caso de testes? Não representa. O objetivo de um teste utilizando Gherkin é reproduzir e testar uma regra de negócio, transformando-a em um teste automatizado, através do Cucumber.

Apesar de parecer muito com um caso de testes, por ter uma pré-condição (Given), uma entrada (When) e um resultado (Then) esse não é o objetivo do Gherkin. Ah, mas eu posso utilizar os casos de testes para gerar alguns testes? Se fizer sentido para a validação da sua aplicação, pode. O que não quer dizer que todos os casos de teste deverão se tornar um teste automatizado ou que para escrever um teste em Gherkin eu precise ter o seu caso de teste equivalente.

Como no Gherkin, temos a palavra Cenário que representa o que será descrito nas próximas linhas, acabou-se fazendo esse link com os cenários de testes e posteriormente com os casos de teste, mas se recorrermos a documentação do Cucumber, podemos ver que o uso da palavra cenário é feito como um sinônimo para a palavra Exemplo (como visto na sessão Rule) e não como um cenário ou caso de teste.

O entendimento dos conceitos nos traz conhecimento para aplicá-los à nossa realidade e otimizarmos o trabalho, garantindo que seremos eficientes ao afirmar que uma entrega está sendo feita com qualidade. Afinal, o processo de testes também precisa ser estruturado, e ter um plano, com seus respectivos cenários e casos de testes nos traz uma segurança de que a validação daquela entrega foi pensada e planejada utilizando técnicas de qualidade e suas aplicações. É possível testar uma aplicação sem cenários e casos de teste, no entanto não teremos garantia de que todas as validações foram pensadas e feitas, bem como não se tem uma documentação como evidência. Dessa forma, falhas são mais prováveis de acontecer. Em geral, as pessoas responsáveis pela qualidade de uma entrega tem diferentes experiências e conhecimentos sobre os processos e técnicas. Com a elaboração de um bom plano de testes, feito a várias mãos, é possível nivelar melhor as pessoas, garantindo que todos os times tenham entregas de qualidade semelhante.

Como foi dito no início do artigo, o mercado de Qualidade de Software está evoluindo, mas é importante que tenhamos certeza de que os conceitos permanecerão corretos com a evolução. E após navegarmos juntos por esses conceitos, espero que tenha ficado um pouco mais claro as relações dos termos que estão tão em alta quando se fala em teste de software.