Requisitos ágeis com BDD

O que você sabe sobre BDD?

Acha que é somente automação de testes? Vamos decifrar…

A tradução de BDD (Behavior Driven Development – Desenvolvimento Guiado por Comportamento), onde o software é construído de fora para dentro (outside-in). Da perspectiva do usuário, com menos desperdício.

BDD é primariamente a especificação executável e a aplicação das técnicas de extração de requisitos em uma linguagem mais informal e clara. Mas muita gente associa o BDD apenas à especificação executável, ou seja, em criar um cenário em Gherkin com o máximo de detalhes para automatizar testes. Isso é apenas uma consequência que pode ou não ser aplicada. Por esse motivo, muitas pessoas deturpam o conceito. Elas querem usar o BDD apenas para automatizar teste. Esquecem-se que o BDD auxilia na concepção e planejamento da solução também; garantindo maior qualidade as entregas para o cliente.

BDD propõe uma forma eficaz de resolver problemas de comunicação entre as equipes de negócio (cliente e Product Owner) e técnica (desenvolvimento e testes),  aumentando o compartilhamento de conhecimento entre elas. Outra grande vantagem, é a documentação dinâmica. Algumas equipes ágeis dizem que o processo de documentar software é demorado.

É comum ouvirmos:

– Times de desenvolvimento no estilo cascata [2] costumam escrever documentos verbosos que os desenvolvedores odeiam ler e têm dificuldade de entender.

– Times ágeis trabalham no lado oposto, escrevendo estórias de usuários sem muita informação.

O BDD ajuda nessa discrepância entre o muito e o pouco.

Umas das técnicas utilizadas no âmbito dos requisitos ágeis é o uso de BDD para refinar o backlog. A prática principal do BDD é escrever as funcionalidades em forma de cenários numa linguagem ubíqua. E para validar esses cenários, escrevemos os critérios de aceite da aplicação.

Uma forma de descrever o comportamento do software utilizando a linguagem natural seria descrever primeiro a estória e em seguida o cenário. Segundo Dan North [1], seguir esse padrão facilita a comunicação entre os envolvidos no projeto. Não é necessário nenhuma ferramenta. A linguagem utilizada para documentar o comportamento é uma narrativa seguindo o modelo:

Como (papel)

Eu quero (funcionalidade)

Então (beneficio/resultado)

O cenário é descrito por critérios de aceitação na seguinte forma:

Cenário : [Descrever o cenário]

Dado que [ Estado inicial do sistema ]

Quando [ Ação a ser realizada no sistema ]

Então [ Coisas que o sistema deve fazer após a ação do Quando ]

Os requisitos devem ser capturados como comportamentos, resultando numa lista de ‘especificações do comportamento’. Na verdade, isso que é levantamento de requisitos. Deve-se definir o que o software deve fazer (modo de agir) e ajustar ele no contexto de valor do negócio [2]. Você escreve cenários de teste em alto nível seguindo uma estrutura e chama a aplicação para o teste de aceitação. Tanto a abordagem de requisitos ágeis quanto de BDD podem ser usados como uma estratégia para a organização. A ideia é ter um retorno sobre o produto a ponto de conseguir posicionar ele de forma mais assertiva dentro do mercado.

 Referências:

[1] http://www.devmedia.com.br/desenvolvimento-orientado-por-comportamento-bdd/21127

[2] http://neelnarayan.blogspot.com.br/2011/04/bdd-is-not-about-tools.html

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/

BDD – Foco no comportamento do sistema

bddImagine como seria muita mais prático se um teste automático pudesse ser escrito por qualquer pessoa do time ou se o teste fosse tão claro e intuitivo que poderia ser considerando uma documentação do sistema. Pois bem, isso é possível usando BDD!!

Atualmente ouvimos falar muito sobre TDD, que é o Test-Driven Development (Desenvolvimento Orientado a Testes), mas a cada dia o conceito de BDD vem ganhando força. E o que seria BDD?

Continue lendo “BDD – Foco no comportamento do sistema”