BDD como metodologia ágil

Por dti digital|

Atualizado: Mar 2022 |

Publicado: Dez 2018

O que é BDD? Qual a diferença entre BDD e TDD? Como ele se relaciona com as metodologias ágeis? Neste artigo, abordamos o Behavior Driven Development e o apresentamos como uma excelente metodologia ágil, que visa unir o time de negócio e o time de desenvolvimento em torno de um entendimento comum: Todos devem falar a mesma língua.

Ao contrário do que alguns podem pensar, esse conceito não se aplica apenas a profissionais de qualidade, mas para sua correta implantação todos os membros do time precisam entendê-lo, e estar comprometidos com um pensamento que gira em torno das necessidades de um usuário real.

Vou fazer uma introdução ao conceito, e falar um pouco sobre como inserir BDD nas equipes de desenvolvimento através da especificação por exemplo.

Sumário

1 O que é metodologia BDD
2 O BDD apresenta um framework baseado em três princípios
3 BDD é um teste automatizado?
4 Processos para iniciar o BDD
5 BDD na prática
6 Prós e Contras do BDD
7 Qual a diferença entre BDD e TDD?
8 BDD no agilismo
- 8.1 Os Agilistas

O que é metodologia BDD

Em tradução livre, BDD é Desenvolvimento Orientado ao Comportamento.

BDD é uma técnica de desenvolvimento de software ágil, criado por Dan North, em 2003, com o intuito de melhorar a comunicação entre um time de desenvolvimento (PO, QA e DEV) para que todos tenham o mesmo entendimento sobre uma determinada funcionalidade.

O BDD foi criado em resposta a problemas que Dan North presenciava através do uso da técnica do TDD – Test Driven Development (Desenvolvimento orientado a testes). A maioria dos times de desenvolvimento e seus alunos tinham dificuldade em como escrever seus testes de acordo com uma determinada User Story.

Então, surge o BDD trazendo a proposta que cenários serão escritos exemplificando comportamentos de uma funcionalidade para que a mesma atinja um objetivo real, agregando valor ao negócio, e assim, dando um suporte ao TDD para que os testes sejam feitos de acordo com os cenários que foram descritos.

Quer ver mais conteúdos como esse?

O BDD apresenta um framework baseado em três princípios

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;

Podemos definir o BDD como a união de várias práticas consideradas ágeis e úteis no desenvolvimento de software, cuja ênfase está nas funcionalidades de alto valor e na redução dos custos de mudança por meio da identificação do que de fato está sendo testado/desenvolvido.

BDD é um teste automatizado?

A resposta é NÃO! Se você é um QA, eu aposto que quando ouviu a palavra BDD pela primeira vez, você achou que BDD era um teste automatizado e que a primeira coisa que deveria ser feita, seria instalar a ferramenta Cucumber, escolher uma linguagem de programação de sua preferência e iniciar a automação dos cenários, e imediatamente, você já pensaria: “Uau! Estou automatizando uma aplicação utilizando o BDD”.

Porque você precisa separar os conceitos de BDD e Cucumber? Ao utilizar o Cucumber, você está apenas aproveitando a sintaxe de Gherkin para realizar a automação de testes.

O BDD nada mais é do que o processo como um todo, um processo de descoberta, o processo que visa entender como uma aplicação irá funcionar. Isso tudo ocorrendo de forma compartilhada e colaborativa entre os membros da equipe de desenvolvimento, onde discutirão uma funcionalidade e escreverão cenários, utilizando uma DSL chamada Gherkin(Given/When/Then), exemplificando assim, o caminho que o usuário irá executar em tal aplicação e o comportamento esperado por ele.

Automatizar esses cenários não é uma obrigação, e sim, uma opção. O BDD deverá ser um ponto de partida para poder entender como o sistema deve se comportar e assim, pensar em formas mais robustas de testes automatizados, seja fazendo um TDD, automatizando camadas de front-end ou mesmo realizando testes automatizados de uma API.

Processos para iniciar o BDD

Como toda metodologia, o BDD também possui um processo a ser seguido, passando pelas etapas de Descoberta, Definição, Formalização e Entrega. A Automação de Testes não entra nessas etapas, mas durante o processo poderá ser decidido qual caminho a ser seguido para sua construção.

Segue abaixo resumidamente o processo de BDD:

Descoberta: Nesta fase fazemos as reuniões de Refinamento da história, onde o PO apresenta a User Story que fará parte daquela sprint.
Definição: Nesta etapa definimos as Regras de negócio daquela história, mostrado exemplos de funcionamento e entendimento compartilhado.

Formalização: Nesta fase elaboramos os protótipos funcionais e os critérios de aceitação (Gherkin).
Entrega: Aqui é feita a entrega da funcionalidade, monitoramento, feedbacks do usuário final e testes de aceitação na aplicação(podendo ser utilizado os cenários de Gherkin para os testes).

BDD na prática

O processo de desenvolvimento do BDD se baseia na escrita de cenários de testes. Cada cenário é um exemplo escrito para ilustrar um aspecto específico de comportamento esperado da aplicação.

Para a escrita do BDD utilizamos uma DSL conhecida como Gherkin, sendo uma linguagem estruturada que se inicia com a sintaxe Given, When e Then (Dado que, Quando, Então).

A cláusula ‘Dado’ descreve as condições e pré-condições;
Já cláusula ‘Quando’, tem o objetivo de descrever um evento ou uma ação;
A cláusula ‘Então’, trata-se de todas as saídas e resultados esperados, descrevendo as informações visíveis ao usuário ou sistemas externos.

A seguir temos exemplos de boas práticas na construção de cenários de um BDD:

Exemplo 1

Feature: Compra de produtos

Como lojas americanas

Eu quero permitir frete grátis para clientes

Para compra acima de R$100,00 de modo que o cliente seja

Estimulado a comprar mais.

Cenário: Permitir frete grátis para clientes que realizam compras acima de R$100,00

Dado que eu esteja realizando uma compra de no mínimo R$100,00

Quando o cliente calcular seu frete

Então será exibido que ele terá o frete grátis para seu pedido

Exemplo 1.1

Feature: Compra de produtos

Como lojas americanas

Eu quero permitir frete grátis para clientes

Para compra acima de R$100,00 de modo que o cliente seja

Estimulado a comprar mais.

Cenário: Taxa de frete será cobrada para compras abaixo de R$ 100,00

Dado que o cliente esteja realizando uma compra abaixo de R$100,00

Quando o cliente calcular seu frete

Então será exibido um valor de frete a ser cobrado

Exemplo 2

(Nesse exemplo uso a técnica Outline)

Feature: Cadastrar um Estudante corretamente

Como um usuário do sistema acadêmico

Eu quero cadastrar dados dos alunos

Para manter os dados dos alunos registrados no sistema acadêmico

Cenário: Realizar cadastro de estudante

Dado que eu tenha clicado no botão <novo cadastro>

E tenha preenchido todos os campos de cadastro

| Last Name | First Name | Enrollment Data |

| ”Silva” | ”João” | ”10/03/2017” |

| ”Santos” | ”Joana” | ”10/03/2017” |

| ”Carlos” | ”Roberto” | ”10/03/2017” |

Quando eu clicar no botão <Cadastrar>

Então aluno será cadastrado e exibido na lista de alunos cadastrados

Exemplo 3

(Aqui eu também uso a técnica Outline)

Feature: Transferir dinheiro através da modalidade PIX

Como cliente do banco

Quero realizar uma transferência de dinheiro pela modalidade Pix

Para que meus amigos recebam o dinheiro em segundos

Cenário A: Realizar transferência PIX com chave válida

Dado que eu esteja realizando um PIX para uma <chave> válida

Quando eu confirmar a transferência para aquela chave

Então o dinheiro será transferido para o favorecido no mesmo segundo

Cenário B: Realizar transferência PIX com chave inválida

Dado que eu esteja realizando um PIX para uma <chave> inválida

Quando eu inserir uma chave inexistente para aquele tipo de chave escolhida

Então transferência PIX não será permitida

Prós e Contras do BDD

Prós: O time se une em um entendimento comum, conseguindo definir os cenários para a geração real de valor ao cliente, e também identificam possíveis falhas de negócio que foram definidos na User Story. A Técnica de Gherkin contribui para pensar em inúmeros caso de falhas quando utilizado a sintaxe Dado, Quando e Então.

Contras: O BDD pode virar um elefante branco caso você se empolgue em escrever inúmeros cenários, pois a maioria das pessoas não gostam de ler, tampouco realizar manutenção na escrita dos cenários. Então, o BDD pode ser uma armadilha caso não seja usado com moderação. É importante ressaltar que os Cenários precisam ser claros, curtos e objetivos, definindo somente as principais regras de negócio daquela Feature, para os demais cenários identificados, eles poderão ser incluídos através da metodologia TDD ou até mesmo em fluxogramas.

Qual a diferença entre BDD e TDD?

TDD é a abreviação para o termo “Test-Driven Development”, que consiste em usar testes como base para o desenvolvimento, e BDD, como citamos anteriormente, é Behavior Driven Development, que significa desenvolvimento orientando a comportamentos.

Tanto TDD quanto BDD são ferramentas de desenvolvimento que têm como prioridade os testes de código, integração contínua e desenvolvimento baseados na metodologia ágil. Essas técnicas são para desenvolvimento orientado a testes. O que as diferencia é o fato de que em TDD você escreve os testes e valida com base nas suas funcionalidades. Já em BDD, você escreve as trilhas e caminhos do problema. Além disso, em BDD é mais humano do que os testes.

BDD no agilismo

Através desta introdução, quis demonstrar que o BDD pode ser tornar um poderoso aliado de metodologias ágeis como Scrum, que visam a melhoria contínua do processo de desenvolvimento. Afinal, através desta prática, podemos obter um refinamento do backlog do produto, garantindo que todos os envolvidos estejam falando uma mesma língua, saibam o que deve ser feito, e evite o retrabalho com constantes melhorias.

Os Agilistas

Para saber mais sobre agilismo, outras metodologias ágeis e como aplicá-las ao seu negócio, confira nosso podcast aqui! Episódios semanais do nosso CEO Marcelo Szuster! Além do nosso podcast, você pode se integrar da cultura interna da dti por meio de nossas vagas disponíveis. Acesse nossa página de carreiras e se inscreva na que mais se encaixa no seu perfil.