ESCRITA DE TESTES FUNCIONAIS UTILIZANDO SEMÂNTICA BDD

Escrever casos de testes funcionais é uma atividade de extrema importância, pois neste momento consistimos o entendimento do escopo e criamos um documento que poderá ser utilizando por qualquer membro do time ou até mesmo pelo cliente em fase de homologação.

No entanto, escrever esse documento pode ser uma tarefa longa e exaustiva dependendo da complexidade da funcionalidade trabalhada e o detalhamento que está sendo atribuído.

As consequências de casos de testes extensos podem ser variadas, como por exemplo:

  • Difícil entendimento de quem está lendo
  • Falta de entendimento do objetivo do que está sendo testado
  • Muito tempo sendo investido na etapa de escrita
  • Difícil manutenção dos templates de testes
  • Difícil reutilização dos templates
  • Entre outros

Entrando mais afundo sobre o tempo investido nessa etapa sabemos que, em times ágeis tentamos sempre trabalhar com tarefas que sejam rápidas de serem concluídas. Considerando que o real objetivo do caso de teste é descrever de forma clara a regra de negócio que deve ser validada, quando inserimos muitos passos podemos deixar o documento confuso e incoeso dificultando sua leitura e entendimento.

Considerando os problemas citados anteriormente que tal aprendermos uma nova forma diferente de escrever casos de testes funcionais utilizando a semântica do BDD que atualmente já está sendo fortemente utilizada em testes automáticos. (Para saber mais sobre BDD clique aqui).

Então vamos ao que interessa!

1º Critério de Aceite

O Guia PMBOK® define em seu glossário:

“Critérios de aceitação / Acceptance Criteria. Os critérios, inclusive requisitos de desempenho e condições essenciais, que devem ser atendidos antes que as entregas do projeto sejam aceitas.” (PMI, p.425)

Em outras palavras, é onde descrevemos a regra de negócio definida pelo Product Owner para cada cenário levantado avaliando se o que foi entregue é testável e está de acordo com o que foi definido no requisito.

2º Contexto

O contexto é composto pelas pré-condições, massa de dados, etc que se repetem para todos os cenários de um critério de aceite e que são necessários para execução do teste.

3º Cenário

Descreve o comportamento que o sistema deverá possuir. O cenário deve ser único e claro referente ao que será validado.

4º Construção do Teste

Agora vem o momento em que utilizaremos a semântica do BDD para estruturar o cenário de teste. Iremos utilizar as palavras chaves Dado, Quando e Então da seguinte maneira:

Dado: Quais pré-condições devem ser verdadeiras para que eu execute o teste?

Quando: Qual ação será executada no sistema que fornecerá o resultado validado?

Então: De acordo com a ação disparada qual o resultado esperado?

Também podemos utilizar a palavra chave E, quando for necessário adicionar uma sentença positiva, seja para Dado, Quando ou Então.

Exemplo:

Dado: que sou uma correntista
E: tenho R$ 500,00 de saldo na minha conta
Quando: eu solicitar um saque de R$ 600,00
E: possuir valor de cheque especial disponível em minha conta
Então: devo receber o valor de R$ 600,00
E: minha conta deve ficar com saldo em R$ 100,00 negativos

E o passo a passo?

É necessário?

Perceba que já temos na nossa documentação o critério de aceite com a regra de negócio, o contexto com as pré-condições do nosso teste, o cenário que será validado e qual o dado de entrada que junto com uma ação minha disparará um resultado que será positivo ou negativo dependendo do critério de aceite.

O como fazer (passo a passo) poderia ser substituído, por exemplo, com a prática do pair testingonde além de disseminarmos conhecimento estamos criando uma cultura de exploração das funcionalidades e requisitos do sistema e evitando o desperdício de tempo em atividades que não serão bem reaproveitadas.

Caso o cliente solicite nossos casos de testes, partimos do pressuposto de que ele já saiba operar o sistema que irá homologar e, portanto ter um documento que esteja claro e objetivo agrega muito mais valor.

Caso vejamos a necessidade de criação do passo a passo não há uma regra que nos impeça de criá-los. O importante é pensarmos se o que estamos criando hoje poderá ser reaproveitado amanhã e se está claro e objetivo.

Vantagens da escrita dos testes utilizando a semântica BDD
  1. Maior entendimento do requisito proposto
  2. Menos tempo investido em escrita de casos de testes
  3. Mais tempo investido em análise de cobertura de testes
  4. Estes testes podem ser utilizados por desenvolvedores na automatização
  5. Fácil manutenção de templates
Exemplos Completos

Exemplo 1:

Critério de Aceite: um caixa eletrônico deve permitir a retirada de dinheiro, quando o cliente não possuir saldo suficiente em conta e possuir limite de crédito aprovado.

Contexto: cliente deve ser correntista, estar com R$ 500,00 de saldo em sua conta e possuir limite de crédito aprovado maior que R$ 600,00.

Cenário: saque em dinheiro em conta corrente com saldo menor que o solicitado e com limite de crédito aprovado.

Dado: que sou uma correntista
E: tenho R$ 500,00 de saldo na minha conta
Quando: eu solicitar um saque de R$ 600,00
E: possuir valor de cheque especial disponível em minha conta
Então: devo receber o valor de R$ 600,00
E: minha conta deve ficar com saldo em R$ 100,00 negativos

Exemplo 2:

Critério de Aceite:  quando o usuário acessar a tela inicial do Facebook deverá ser apresentado os campos para novo cadastro e após preenchê-los e clicar no botão “Criar Conta” uma nova conta no Facebook com os dados informados deverá ser criada.

Contexto: usuário deve possuir uma conta de e-mail ou número de celular.

Cenário: cadastro de nova conta no Facebook

Dado: que estou na tela inicial do Facebook
Quando: eu preencher os campos de cadastro
E: clicar no botão “Criar conta”
Então: a mensagem “Conta cadastrada com sucesso” deverá ser apresentada
E: serei redirecionado para a página inicial da minha conta no Facebook

Perceba que não especificamos passo a passo o que deve ser feito e sim o comportamento de uma história dentro do sistema.

Uma boa prática é levantarmos os cenários que serão validados dentro do projeto e então estruturarmos eles utilizando a semântica BDD antes da reunião de planejamento. Dessa forma os cenários podem discutidos com a equipe e apresentados ao Product Owner para garantir que estes estão de acordo com as especificações do escopo. Para entender melhor sobre planejamento de testes clique aqui.

Boas Práticas:
  • Os casos devem descrever um comportamento e não um passo a passo;
  • Precisam seguir uma linguagem ubíqua, ou seja, qualquer pessoa que ler entenderá o objetivo;
  • O time integrante do projeto deve ser envolvido no refinamento dos casos;
  • Todos os cenários devem ser independentes;
  • Os casos devem ser validados com o Product Owner
Conclusão

A escrita de casos de testes é um processo importante na nossa área, pois este provê um documento com todos os cenários de negócio que serão exercitados durante o projeto. Porém, gastamos muito tempo na criação desses documentos aumentando a sua complexidade em termos de manutenção, entendimento, etc. Na era ágil em que estamos desperdício de tempo quase chega a ser um pecado e portanto buscamos aplicar técnicas que nos ajudam a diminuir o tempo das tarefas cotidianas mantendo ou aumentando a qualidade das mesmas. O BDD é uma técnica que inicialmente foi aplicada somente para testes automatizados, mas que pode perfeitamente ser aplicada em testes funcionais. Com a escrita de testes funcionais utilizando semântica BDD conseguimos criar um caso de teste muito mais claro, objetivo e enxuto nos dando muito mais tempo para análise de cobertura dos testes e consequentemente nos dando a oportunidade de melhorar a qualidade do produto entregue.

Referências

[1] https://escritoriodeprojetos.com.br/expectativas-requisitos-criterios-de-aceitacao-restricoes-premissas

[2] http://www.matera.com/br/2016/10/26/bdd-validando-o-comportamento-sistema/