O que é BDD? Como implementar esse conceito na sua equipe?

Está sem tempo de ler agora? Que tal ouvir o artigo? Experimente no player abaixo!

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

 

Se eu for explicar o que é BDD de uma forma breve, saiba que se trata de uma ferramenta de desenvolvimento ágil que tem como principal objetivo integrar regras de um negócio à linguagem de programação, a fim de aprimorar o comportamento de um software.

No meio de tantas e tantas metodologias de desenvolvimento ágil, creio que no mundo de teste de software nenhuma é tão famosa quanto essa, que é a sigla para o termo em inglês Behavior Driven Development. 

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 de que a primeira coisa que veio à sua mente foi: “Preciso instalar o Cucumber!!!”

E após 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 desenvolvida em Gherkin (guarde esse nome), na qual é suportado pelo Cucumber. Ou seja, 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 têm 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 o Cucumber.

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

Afinal, o que é o BDD?

Em uma definição resumida, podemos dizer o que é BDD, ou seja, Behavior Driven Development, é um processo colaborativo que envolve múltiplos membros do time, trabalhando em conjunto com o PO (Product Owner) 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, portanto, está na conversa, no 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 seguido, 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.

As quatro fases do processo de BDD

Como mencionado, as quatro fases do processo de BDD são: descoberta, definição, formalização e entrega. Por isso, vamos, agora, exercitar cada uma delas.

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: nesse 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 Gherkin. Poré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, tais como specification workshops, discovery workshop, example mapping, 3 amigos, dentre outras.

Porém, vamos focar aqui nas duas principais técnicas (na minha opinião) de BDD: 

• Example Mapping;
• 3 amigos. 

 

Meu objetivo 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, ajuda a levantar todos os requisitos possíveis para cobrir toda a história.

 

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”. Entretanto, é 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.

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. 

Isso acontecerá 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, mas, sim, ao comportamento do usuário, que é o que prega o BDD.

Dessa forma, temos a seguinte timeline a ser seguida:

 

BDD, TDD e ATDD: o que são e quais as diferenças?

Mas além de saber o que é BDD, é essencial que você, enquanto Product Owner, também saiba o que é TDD, ATDD e as principais diferenças entre os três conceitos. Então, vamos às explicações!

TDD

TDD é a sigla para o termo em inglês Test Driven Development, que na tradução para o português significa Desenvolvimento Orientado a Testes.

Nesse modelo, os desenvolvedores criam códigos fontes de um determinado teste automatizado com o propósito que esse falhe para, somente depois, codificar a função necessária para o teste ser validado.

O principal objetivo com o Desenvolvimento Orientado a Testes é garantir a qualidade do software. Isso acontece porque é realizado um teste para que, se uma certa função for alterada, o comportamento esperado em resposta a essa ação errônea não gera uma mudança indesejada.

Aqui, vale uma curiosidade para você! Foi justamente com base no TDD que o BDD foi criado, englobando todos os critérios e formas de aplicação que já citamos aqui.

ATDD

Abreviação do termo em inglês Acceptance Test-Driven Development, ATDD é Desenvolvimento Orientado a Testes de Aceitação.

Nessa ferramenta de desenvolvimento ágil, todos os critérios e requisitos de aceite para cada história são levantados de forma colaborativa, ilustrando também possíveis cenários de testes.

Para isso, no entanto, é necessário envolver todo o time, incluindo o Product Owner, desenvolvedores, designers, entre outros profissionais que, por meio de reuniões fazem o levantamento dos problemas que precisam ser sanados com o software que está sendo desenvolvido, expectativas do cliente, e outros pontos relacionados.

Lembra da técnica “3 amigos” que citamos? Pois então, ela tende a ser bastante utilizada no conceito ATDD para obtenção das perguntas e respostas necessárias para a evolução do projeto.

Principais diferenças entre BDD, TDD e ATDD

Para entender as principais diferenças entre BDD, TDD e ATDD, a primeira ideia que você precisa ter em mente é que o Behavior Driven Development foi criado com o intuito de substituir o Test Driven Development.

Na verdade, o BDD veio para complementar o conceito já aplicado no TDD, deixando essa ferramenta de desenvolvimento ágil ainda mais completa, dinâmica e precisa.

Com isso em mente, saiba que as três técnicas visam o uso de testes de código, evolução e integração contínua. Em outras palavras, todas são orientadas a testes.

Entretanto, apesar do ponto de semelhança, há uma diferença sutil entre elas. Por exemplo, no Test Driven Development os testes são escritos e validados com o objetivo de que funcionem corretamente. No Behavior Driven Development a descrição é sobre como um determinado problema no software deve se comportar.

O Acceptance Test-Driven Development, por sua vez, contempla também a idealização de diferentes cenários possíveis de realizar os testes.

Você pode considerar também que essas três técnicas são incrementais. Na prática, isso quer dizer que a cada nova história inserida é necessária a inclusão de um novo teste.

Por fim, todas têm o mesmo objetivo: a entrega de um produto de qualidade, com todos os potenciais pontos de erros previamente identificados e ajustados, a fim de entregar para os usuários finais a melhor experiência que for possível.

Dica de leitura: “​​Como melhorar a experiência do cliente? Soluções de pagamento personalizadas podem ser a resposta!“

Quais são as vantagens ao escolher o BDD?

Mas se após conhecer todas essas ferramentas de desenvolvimento ágil você resolveu ficar com a BDD, saiba que pode obter uma série de vantagens com o seu uso — desde que esse seja feito corretamente!

Entre os benefícios do Behavior Driven Development que mais se destacam estão:

• visão global do projeto;
• aprimoramento da comunicação do time;
• oportunidade de compartilhar conhecimento;
• emissão mais dinâmica de documentações.

Visão global do projeto

Por meio do uso do BDD é possível desenhar cenários e testar a solução antes de o projeto estar finalizado. Com isso, os profissionais têm uma visão ampla de tudo o que pode acontecer e de falhas que podem ocorrer, se antecipando a elas previamente à entrega do produto.

Isso evita erros e fracassos posteriores, bem como otimiza o alcance de resultados mais expressivos e significativos.

Aprimoramento da comunicação do time

Devido a sua característica de reunir os envolvidos para bater diferentes possibilidades, a estratégia Behavior Driven Development melhorar a comunicação do time e dos profissionais envolvidos.

Em outras metodologias, geralmente, o trabalho é individual, o que pode impactar na comunicabilidade, gerar ruídos nas conversações e, consequentemente, afetar o resultado do projeto.

Oportunidade de compartilhar conhecimento

O mesmo motivo fomenta o compartilhamento de conhecimento entre os colaboradores. Afinal, estarão trabalhando juntos, apresentando e dividindo ideias, pontos de vista, experiências e maneiras distintas de pensar que podem se complementar.

Emissão mais dinâmica de documentações

Os frameworks do BDD viabilizam a emissão de documentações automaticamente. Essa dinâmica, por sua vez, otimiza o tempo do PO e da sua equipe, tornando a geração documental muito mais prática e rápida.

Então, ficou claro o que é BDD?

Como você pôde 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!