Gestão

O que é BDD? Conheça o que é Behavior Driven Development e o que é preciso para implementá-lo na sua equipe

Publicado em 25 de junho de 2020 por Redação Zoop

Escrito por André Leite, Head de Qualidade e Vinicius Trindade, Analista de Testes Sênior na Zoop.

Procurando saber o que é BDD? No meio de tantas e tantas metodologias de desenvolvimento ágil, creio que no mundo de teste de software nenhuma é tão famosa quanto o Behavior Driven Development, ou apenas, BDD. 

Porém, muitas das vezes, a sua associação incorreta como um framework de automação de testes faz com que a metodologia BDD não seja implementada da forma correta, sendo até algumas vezes abandonada.

Neste artigo, vamos falar melhor sobre essa metodologia, seus processos, técnicas e sua principal ideologia: o entendimento compartilhado.

BDD não é automação de testes? 

Se você é um analista de teste e, algum dia, já pensou o que é BDD, tenho certeza que a primeira coisa que veio na sua mente foi: 

“Preciso instalar o Cucumber!!!”

E depois de fazer a instalação, e conseguir criar o seu primeiro teste automatizado usando o Cucumber em parceria com alguma linguagem de programação, você com certeza pensou: 

Cara, eu estou automatizando em BDD!

Na verdade, não! Você “apenas” criou um teste automatizado, a partir de uma documentação executável criada em Gherkin (guarde esse nome), na qual é suportado pelo Cucumber. 

Não houve aplicação do BDD nesse caso!

Mas por que muitos confundem ou associam o que é BDD unicamente a testes automatizados com Cucumber?

Tanto o BDD quanto o Cucumber possuem uma pequena similaridade, a utilização do Gherkin como padrão de escrita de critérios de aceitação. E é nesse ponto que toda a confusão se inicia. 

Não existe uma obrigatoriedade de escrever os critérios de aceitação no BDD utilizando Gherkin. Porém, existe um aconselhamento por ser a linguagem que mais se aproxima da descrição do comportamento do usuário com a aplicação.

Você pode automatizar testes de software utilizando Cucumber/Gherkin dentro da metodologia BDD. Mas você não está fazendo BDD, por estar apenas aplicando automação de testes com Cucumber.

É importante que essa separação de conceitos esteja clara para que você tenha sucesso no entendimento e na aplicação do que é BDD.

Então, o que é o BDD?

Em uma definição resumida, podemos dizer o que é BDD, ou seja:

“Behavior Driven Development, ou BDD, é um processo colaborativo que envolve múltiplos membros do time, trabalhando em conjunto com o PO para descobrir e refinar os requisitos usando, para isso, conversas estruturadas sobre exemplos de uso e comportamento de um sistema ou funcionalidade, buscando o entendimento compartilhado.”

A alma do BDD está na conversa, alinhamento constante e principalmente no entendimento compartilhado entre todos os membros do time que estão envolvidos na parte negocial do desenvolvimento de uma história, geralmente QAs, DEVs e POs. 

Como toda metodologia, o BDD também possui um processo a ser seguindo, passando pela Descoberta, Definição, Formalização e Entrega — a automação dos testes aqui é uma opção, e não uma obrigação. 

Porém, se estamos falando de times ágeis, nos quais o foco está, na maioria das vezes, em entregar de forma ágil, com o máximo de qualidade possível, é recomendável a automação de testes, tanto no nível unitário (usando TDD) quanto no nível funcional (usando ATDD).

A imagem abaixo ilustra, resumidamente, o processo do BDD.

Passo a passo da metodologia BDD

Vamos, então, exercitar cada fase do processo do BDD.

1. Descoberta

Quando: cerimônia de refinamento (ou Grooming)

Participantes: QAs, DEVs, POs e quaisquer outros que possam contribuir com o refinamento da história.

Objetivo: na fase de descoberta, o PO explanará  a história que fará parte de uma sprint, falando sobre a visão a nível de negócio, as funcionalidades, fluxos e regras de negócio que já foram mapeados por ele, para que todos os envolvidos possam ter o mesmo entendimento sobre a finalidade da história em questão.

Após a explanação, todos os envolvidos iniciarão uma conversa estruturada, utilizando técnicas de BDD (que veremos mais à frente) para levantar exemplos de uso e comportamento do usuário com a funcionalidade em questão.

A ideia é que sejam geradas dúvidas e que cada resposta possa virar uma nova regra de negócio, um critério de aceitação ou até mesmo uma nova história de usuário na fase de definição.

2. Definição

Quando: cerimônia de refinamento (ou Grooming)

Participantes: QAs, DEVs, POs e quaisquer outros que possam contribuir com o refinamento da história.

Objetivo: com  todas as perguntas necessárias, o objetivo é definir quais delas se tornaram regras de negócios, critérios de aceitação ou novas histórias.

Essas definições, logicamente, se darão por meio da conversa e alinhamento entre os envolvidos na cerimônia de refinement. 

A ideia é que, após a definição, todos os itens levantados possam ser formalizados na fase seguinte..

3. Formalização

Quando: geralmente, por precisar de um pouco mais de esforço para se construir uma nova história ou critérios de aceitação, é recomendado que a formalização seja realizada fora da cerimônia de refinement.

Responsável: QAs, DEVs, POs ou qualquer um que seja responsável pela criação dos artefatos.

Objetivo: neste caso, o objetivo é transcrever todos os itens levantados em uma linguagem amigável e de fácil entendimento por todos. 

No caso dos critérios de aceitação, recomenda-se o uso do GherkinPorém, pode ser utilizado qualquer outro formato que seja realmente entendível por todos, como Protótipos, Wireframes (no caso de aplicações web ou mobile) ou Wiremocks (no caso de APIs).

4. Entrega

Quando: geralmente, durante a cerimônia de review e durante todo o tempo em que a história estiver em produção.

Responsável: QAs, DEVs, POs ou qualquer um possa apresentar o software de valor desenvolvido.

Objetivo: após a execução de todo o desenvolvimento e testes da história, podemos então apresentar para o PO, durante a cerimônia de review para validação do entregável e posteriormente para produção. 

Ideal que a funcionalidade seja monitorada após a promoção para o ambiente de produção, para que possam ser gerados feedbacks relacionados à utilização dos clientes na aplicação.

Quais técnicas de BDD podemos utilizar?

Agora que você sabe melhor o que é BDD, saiba que existem várias técnicas que possibilitam o levantamento de requisitos, como specification workshops, discovery workshop, example mapping, 3 amigos, dentre outros.

Porém, vamos focar aqui nas 2 principais técnicas (na minha opinião) de BDD: Example Mapping e 3 amigos

A ideia não é explicar por completo as duas técnicas, mas passar um resumo que seja minimamente entendível para que possa ser aplicável por você.

Example Mapping

Como dito anteriormente, dentro do processo de BDD —  mais especificamente nas fases de Descoberta e Definição — será explanada a história e, com isso, dúvidas sobre o exemplo de uso serão levantadas para que, posteriormente, possam se tornar uma regra de negócio e critérios de aceitação. 

No caso, o Example Mapping é uma técnica que engloba essas duas fases e, de uma forma estruturada, ajudar a levantar todos requisitos possíveis para cobrir toda a história.

Example Mapping - Metodologia BDD

Durante a explanação do PO sobre a história e as regras de negócios levantadas previamente, os demais envolvidos escreverão em um post it as dúvidas que surgirem  (cada dúvida em um post it diferente). 

Após o fim da explanação, será iniciada uma conversa de forma que todas as dúvidas sejam respondidas. 

Assim, as  respostas deverão ser escritas em post its, conforme especificidade (critérios de aceitação, regras de negócios ou histórias).

O time-box padrão é de 25 minutos para cada história, mas recomendo que no início não fique preso a ele somente se atente para não fazer com que a reunião fique demorada, de acordo com o feeling da equipe.

A reunião deve acabar quando todos os membros concordarem que a cobertura levantada para a história foi a máxima possível.

3 Amigos

A técnica “3 amigos” não é absolutamente diferente do “Example Mapping”, porém, acredito ser mais simples e de fácil implementação. 

A diferença primordial é basicamente a não presença dos post its. O PO continua explanando a história, e as dúvidas e respostas são realizadas de forma mais dinâmica, sem necessariamente aguardar o fim da explanação para levantá-las  ou para definir os critérios

É, de fato, mais dinâmico e menos “rígido”. Porém, é necessário que os envolvidos tenham o máximo de comprometimento em, de fato, conseguirem tirar o máximo de cobertura possível da história.

Passo a passo da técnica "Amigos" na metodologia BDD

Minha sugestão é que se inicie com Example Mapping, para conseguir entender a dinâmica e os outputs. 

Quando estiverem confortáveis, fazer a migração para a “3 amigos”. Assim, acredito, terão mais sucesso na aplicação das técnicas.

Mas e a automação de teste?

Sim! A automação está presente aqui, mas, como dito anteriormente, é opcional. 

Se aplicado corretamente, o Behavior Driven Development abrirá uma excelente janela para que se possa criar os scripts de testes automatizados, seja usando Cucumber, Rest Assurance, Robot Framework, Postman ou qualquer outra ferramenta de testes automatizados, de forma paralela com o desenvolvimento, agilizando não somente a execução dos testes, mas também a entrega da história para o PO e consequentemente para o ambiente de produção.

O único ponto de atenção é: se atentar para que os critérios de aceitação que serão escritos (geralmente por QA) não fiquem orientados a implementação ou aos testes que serão realizados, e sim ao comportamento do usuário, que é o que prega o BDD.

Dessa forma, temos a seguinte timeline a ser seguida:

Timeline da metodologia BDD

Como você pode ver , o BDD é uma excelente metodologia de desenvolvimento ágil, que envolve não somente o analista de teste, mas todos os membros da equipe

Apesar de não ser um framework de testes automatizados, pode ajudar bastante na criação de estruturas robustas de testes automatizados, como “continuous testing”, por exemplo. Mas isso fica para um outro artigo!

Espero que tenham gostado e ajudado você a compreender melhor o que é BDD.

Até a próxima!

Diga como podemos lhe ajudar!
Avalie o artigo