O BDD é sem sobra de dúvidas um dos assuntos mais famosos quando se fala em documentação de testes ou automação. Mas… Essas associações estão corretas?

Neste artigo, mergulharemos fundo no mundo do Behavior Driven Development, desvendando suas técnicas, processos e explorando como essa abordagem pode ser efetivamente aplicada.

Vamos lá!!!

O QUE É BDD?

Antes de explicarmos o que é o BDD, precisamos desmitificar alguns pontos importantes. Vamos lá:

Mito 1: Escrevendo documentações com BDD

Tenho certeza que você já ouviu essa frase:

“E aí, já criou os BDDs dessa história de usuário?”.

– Alguém que não conhece BDD …

Essa é uma das grandes pérolas envolvendo o BDD.

O BDD não é um padrão ou técnica de documentação. Porém, devido a suas características, é sugerido o uso do Gherkin ao invés de um modelo procedural, por ser mais fácil e legível descrever comportamentos de usuários.

Então, se você usa o padrão Dado, Quando e Então para criar os cenários de testes, você está fazendo uso da linguagem Gherkin e não do BDD.

Mito 2: Vamos automatizar em BDD

Essa frase, se você não escutou, talvez já tenha falado …

“Opa! Vamos usar BDD para automatizar esse cenários!”

– Alguém que também não conhece o BDD …

Esse talvez seja um dos grandes mitos que levaram o BDD a ser pouco compreendido pela comunidade. O BDD não é uma ferramenta ou framework para automação de testes. Podemos dizer que a automação de testes é algo derivado de todo o processo, mas está longe de ser o seu objetivo principal.

Mas então, o quê é o BDD?

Agora que já sabemos o que o BDD não é, vamos entender o que de fato é o BDD.

BDD (Behavior Driven Development ou Desenvolvimento Guiado por Comportamento), é um processo colaborativo que reúne diferentes membros de uma equipe para explorar e aprimorar requisitos por meio de discussões estruturadas sobre exemplos de uso e comportamento de um sistema ou funcionalidade. A base do BDD reside nas conversas, no constante alinhamento e, principalmente, no desenvolvimento de um entendimento compartilhado.

A essência do BDD é a interação, onde equipes multidisciplinares, incluindo QA, desenvolvedores, Product Owners (PO) e outros membros, se envolvem na definição dos aspectos negociais de uma história. Isso cria uma sinergia que impulsiona o desenvolvimento, garantindo que todos tenham uma visão comum do que está sendo criado.

Similar a qualquer metodologia, o BDD segue um processo que envolve etapas de descoberta, definição, formalização e entrega. Importante destacar que a automação dos testes, embora seja uma opção valiosa, não é uma obrigação no BDD, permitindo flexibilidade na abordagem de teste adotada. E caso a automação de teste seja adotada, é sugerido que as automações sejam realizadas nos níveis de unidade e integração, pois são camadas mais próximas do momento do desenvolvimento do sistema ou da funcionalidade.

Agora que entendemos o que e o BDD, precisamos entender melhor as etapas do seu processo.

O PROCESSO DO BDD

Descoberta

Na fase de Descoberta, as equipes multidisciplinares, incluindo QAs, DEVs, POs e demais membros da equipe, se reúnem para discutir e entender os requisitos da história que será desenvolvida. O foco está na visão de negócios, nas funcionalidades e nas regras de negócios envolvidas na história. Durante essa fase, ocorre uma conversa estruturada para identificar exemplos de uso e comportamento da funcionalidade, a fim de garantir que todos tenham uma compreensão compartilhada da história.

Definição

Na etapa de Definição, as perguntas levantadas durante a fase de Descoberta são refinadas em regras de negócios, critérios de aceitação ou até novas histórias. As equipes continuam a colaborar para alinhar-se quanto à abordagem e detalhes da implementação. Essa é uma fase importante para garantir que todos os aspectos da funcionalidade sejam claros e bem compreendidos pela equipe.

Formalização

Depois de definir os aspectos da funcionalidade, a Formalização entra em cena. Aqui, as informações coletadas nas etapas anteriores são transformadas em documentos ou artefatos de fácil compreensão. Os critérios de aceitação, por exemplo, podem ser expressos em Gherkin, que é uma linguagem simples e legível, mas não é uma obrigação. O objetivo é ter uma descrição concisa e compreensível de como a funcionalidade deve se comportar.

Entrega

Com os critérios de aceitação definidos e formalizados, a equipe parte para a implementação da funcionalidade. Após o desenvolvimento e os testes, a funcionalidade é apresentada ao PO para validação durante a cerimônia de revisão. Uma vez validada, a funcionalidade é promovida para o ambiente de produção. A equipe continua a monitorar o desempenho da funcionalidade após a entrega, colhendo feedback dos usuários para garantir que atenda às expectativas.

AS TÉCNICAS DO BDD

Agora que você compreende o conceito do BDD, é importante saber que existem várias técnicas que auxiliam no processo de levantamento de requisitos. Essas técnicas facilitam a colaboração entre as equipes e ajudam a garantir um entendimento compartilhado das funcionalidades a serem desenvolvidas. Algumas dessas técnicas incluem specification workshops, discovery workshops, example mapping, 3 amigos, entre outras.

Aqui, vamos nos concentrar apenas no Example Mapping e Los 3 Amigos, que para mim, são as mais fáceis e que entregam um bom resultado. Será uma explicação mais resumida, mas deixarei links no final do post para que vocês peguem mais detalhes sobre essas duas técnicas.

Example Mapping

O Example Mapping é uma técnica que visa estruturar as discussões sobre os requisitos de forma organizada. Nessa abordagem, a equipe se reúne para identificar exemplos concretos de comportamento de uma funcionalidade. A técnica envolve as seguintes etapas:

• Discussões: A equipe se reúne para discutir a funcionalidade em questão. Essa discussão envolve todos os papéis relevantes, incluindo QAs, desenvolvedores e POs e qualquer outro membro que seja importante para a discussão.
• Mapeamento de Exemplos: Durante a discussão, a equipe identifica exemplos concretos que representam o comportamento esperado da funcionalidade. Esses exemplos são mapeados visualmente para uma melhor compreensão.
• Refinamento de Cenários: Os exemplos mapeados são refinados para criar cenários de teste mais detalhados e abrangentes. Isso ajuda a identificar lacunas nos requisitos e a garantir que todos os casos importantes sejam considerados.

O Example Mapping oferece benefícios significativos, como a criação de um entendimento compartilhado entre as equipes e a identificação precoce de possíveis problemas ou lacunas nos requisitos.

Los 3 Amigos

A técnica dos 3 Amigos envolve a colaboração de três papéis-chave: o PO (representando os requisitos), o Desenvolvedor (representando a implementação) e o QA (representando os cenários de teste). Juntos, esses “amigos” discutem a história em questão, trazendo diferentes perspectivas para garantir que todos os aspectos sejam considerados.

• Colaboração Tripla: Cada um dos “amigos” traz sua perspectiva única para a discussão. O PO descreve os requisitos, o Desenvolvedor traz insights sobre a implementação técnica e o QA contribui com cenários de teste.
• Cobertura Abrangente: A abordagem dos 3 Amigos garante que os requisitos sejam abordados de forma abrangente. As discussões entre os três papéis ajudam a identificar cenários que podem ter passado despercebidos de outra forma.

O “Los 3 Amigos” oferece benefícios como feedback precoce, alinhamento entre as partes interessadas e a garantia de que a história seja compreendida de maneira completa por todos os envolvidos.

Essas técnicas são fundamentais para a execução bem-sucedida do BDD, pois facilitam a comunicação entre as equipes e garantem que as funcionalidades sejam desenvolvidas de acordo com os requisitos do usuário e do negócio.

“E a minha automação…?”

Como dito anteriormente, caso o processo de automação seja incorporado ao BDD, é sugerido que seja realizado em camadas abaixo da camada de aceitação. Porém, você ainda pode (e deve) trazer as etapas de automação dos cenários levantados na fase de Descoberta e Definição para garantir o correto comportamento da sistema onde os testes unitários e integrados não chegam.

Apesar de ter um processo e técnicas claras, o BDD não está blindado de adaptações para que se torne mais adequado a realidade do seu time ou domínio. Desde que a colaboração entre membros do time e o entendimento compartilhado, características base do BDD, não sejam perdidos.

CONCLUSÃO

Como podemos ver, o BDD é realmente algo muito maior do que documentações escritas em Gherkin ou automações de testes.

Se aplicado da forma correta, pode ser uma excelente aliado ao processo de desenvolvimento ágil do seu time.

---

E ai… Já conhecia o BDD dessa forma?

Até o próximo post!

Valeu!

---

Veja nossos produtos na Robot Store e adquira você também as nossas camisas personalizadas.

---

Esse post é uma releitura de um antigo post, criado por mim, em parceria com a Zoop em 2020.

https://zoop.com.br/blog/gestao/o-que-e-bdd-como-implementar/

Example Mapping: https://cucumber.io/blog/bdd/example-mapping-introduction/

Los 3 Amigos: https://cucumber.io/docs/bdd/who-does-what/