10/15/2019 5:34:32 PM

Utilizando BDD em Requisitos

Tecnologia bdd teste tdd product owner

A grande vantagem desta prática não é gerar testes, e sim pensar no design e nas regras negócios antes de escrever qualquer linha de código.

Nos dias atuais é bem comum ver diversas formas de trabalhar com requisitos, seja no modelo tradicional (Cascata) ou em modelos ágeis, porém sempre nos questionamos sobre qual a melhor forma de identificar se o conteúdo produzido pelo time é satisfatório ao cliente. O que podemos definir como padrão, seja no modelo tradicional ou utilizando requisitos ágeis, é que ambos precisando de “Critérios de Aceitação”, ou seja, algo que defina os critérios básicos para aceite da entrega do requisito.

Um ponto muito importante para se ressaltar é que os critérios de aceitação (independente da forma que for construído), não substituem o plano de teste. Eles serão utilizados como base para a construção de um plano de teste, ou pode ser um resumo otimizado de um plano de teste quando existente.

Mas vamos lá, e o tal do BDD (Behavior Driven Development) o que é?

O BDD (Desenvolvimento orientado ao comportamento) é uma técnica de desenvolvimento de software ágil que surge através de uma crítica de Dan North ao TDD (Test Driven Development - Desenvolvimento orientado a testes), onde ele visava otimizar o conceito de “verificação e validação” já aplicado, mas tornando mais eficiente a construção de cenários a serem testados e/ou desenvolvidos.

Em resumo o TDD deve ser escrito antes da codificação da aplicação, e assim com base nas falhas dos primeiros testes, o time pode se basear nestes testes falhos para implementar o resultado esperado e que atenda o TDD. Porém a grande vantagem desta prática não é gerar testes, e sim pensar no design e nas regras negócios antes de escrever qualquer linha de código.

Assim surge o BDD, como uma prática que levaria o time de desenvolvimento a pensar no comportamento do usuário para entender o que deve ser feito. E atualmente através de conceitos e ferramentas, ele já pode ser aplicado por todos os membros do time, e não apenas pelos desenvolvedores.

Um erro cometido por muitos analistas de negócio e PO’s (Product Owner) é pensar que podemos primeiro escrever requisitos e depois definir os critérios de aceitação. O BDD é uma técnica de critério de aceitação e pode ser escrito antes, durante ou após a elaboração do requisito. Como o mundo respira ágil neste momento, é comum que os requisitos sejam feitos em formato de estórias de usuários, e com elas não será diferente a aplicação.

O BDD apresenta um framework muito simples, vejamos:

  • A área de negócios e o time de desenvolvimento precisam se referir a mesma parte do sistema da mesma forma;
  • Toda parte do sistema precisa ter um valor identificável e verificável para o negócio;
  • Analisar, projetar e planejar tudo de cima a baixo tem retorno decrescente;
Para utilização do BDD vamos utilizar a seguinte estrutura (Given, When e Then (Dado que, quando e então). Mas antes disso precisamos entender as necessidades do negócio, separá-las em funcionalidades (Features), e escrever seus cenários como abaixo:


No exemplo acima já temos uma funcionalidade definida, mas como testar se atente a todos os cenários possíveis? Para isso vamos definir cenários de negócio e criar os seus respectivos critérios de aceitação. Lembrando que se já soubermos estes critérios, a Elicitação da funcionalidade fica muito mais simples. Vejamos os exemplos de cenários:


Mas podemos incrementar os cenários e deixá-los mais específicos e precisos. O nível de detalhamento dos cenários pode ser negociado com o time, mas vale lembrar que quando temos as informações que são imprescindíveis, sempre é bom descreve-las. 

Vejamos abaixo como ficaria o exemplo anterior enriquecendo com alguns detalhamentos:



Veja que o elemento “E” pode ser utilizado quanto for necessário para incrementar o critério de aceitação em qualquer parte da estrutura (Dado, Quando e Então). Também é importante ressaltar que o teste pode ser descrito de forma “POSITIVA” ou “NEGATIVA”, ou seja, descrevendo um cenário que represente um tratamento do sistema para negar operações. Exemplo:

As estórias podem ter N cenários como podem ter N testes no mesmo cenário, tudo vai depender do conteúdo abordado na estória. Uma dica, mantenha as estórias mais objetivas possíveis, assim seus testes geralmente tendem a ser objetivos também.

Outro ponto importante é que por ser uma prática voltada para o desenvolvimento conseguimos aumentar a quantidade de testes automatizados, e também realizar a manutenção dos existentes que foram alterados. Viabilizando a análise prévia de impactos baseada nos comportamentos esperados e seus possíveis caminhos alternativos. Além do comparativo com os demais comportamentos que foram definidos.

Em resumo, estórias ou requisitos que não possuam critérios de aceitação (independente do modelo adotado) ficam suscetíveis a falhas no aceite e passiveis de erros de negócio. O modelo BDD, mesmo que não perfeito no início da sua aplicação, reduz significativamente as falhas de entregas.

Espero que esse conteúdo seja útil para seus projetos, e se você gostou desse material, compartilhe com seus pares e colegas! Até a próxima!



 

Compartilhe: