BDD (Behaviour Driven Development) -

Desenvolvimento Orientado por Comportamento

Para que serve:
BDD serve para criar testes e integrar regras de negócios com a linguagem de
programação, focando no comportamento do software. Além disso, ainda melhora a
comunicação entre as equipes de desenvolvimento e testes, aumentando o
compartilhamento de conhecimento entre elas.

Em que situação é útil:

Esta metodologia é útil em projetos de software ágeis, que são construídos em várias
iterações e estão sofrendo alterações ao longo do seu ciclo de vida. Quanto maior o
projeto, mais difícil será a comunicação. Entretanto, BDD propõe uma forma eficaz de
resolver estes problemas.

Resumo:
Quando se estuda Engenharia de Software, aprende-se que todo sistema tem um
tempo de vida útil, e que uma série de fatores podem contribuir para aumentar ou
diminuir este tempo: arquitetura, modelagem, tecnologia utilizada, aceitação do
mercado, etc. No entanto, nenhuma empresa desenvolve um sistema pensando no dia
em que ele deixará de atender as necessidades do seu cliente, apesar desta ser uma
verdade certa.

Neste ciclo, o sistema passa a maior parte do tempo sofrendo alterações. E estas
manutenções, sejam elas corretivas ou não, podem melhorar ou piorar o sistema,
dependendo da forma que forem implementadas. Pensando neste e em outros
problemas, Kent Beck apresentou ao mundo em 2003, através do seu livro “Test-
Driven Development”, uma técnica para criar sistemas baseados em testes que visa
garantir a qualidade e a funcionalidade do software durante este ciclo.

Embora TDD seja uma técnica testada e aprovada por grandes desenvolvedores ágeis,
muitas equipes de desenvolvimento ainda caem em algumas armadilhas e mal-
entendidos do tipo: por onde começar, o que testar e o que não testar. Isto sem falar
que quem escreve os testes são os desenvolvedores, mas quando a equipe de
qualidade vai testar, ela se preocupa com o comportamento do sistema e não com os
testes unitários. Desta forma, não há comunicação eficiente entre as duas equipes no
nível de código.

Para tornar a aplicação de TDD mais simples e ajudar as equipes de desenvolvimento

a resolverem as questões mencionadas acima, surgiu o Behaviour Driven Development
(BDD).
O que é TDD?
Test Driven Development(TDD) ou, em português, Desenvolvimento Dirigido por testes
é uma técnica de desenvolvimento de software que se baseia em um ciclo curto de
repetições. Primeiramente o desenvolvedor escreve um caso de teste automatizado
que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido
código que possa ser validado pelo teste. Posteriormente este código será refatorado
para colocá-lo sob padrões aceitáveis.

Kent Beck declarou em 2003 que TDD encoraja designs de código simples e inspira
confiança. Do ponto de vista de Robert C. Martin, escritor do livro “Agile Software
Development”, o objetivo de TDD é a especificação e não a validação, ou seja, é a
maneira de pensar através das necessidades do projeto antes de escrever o código
funcional.

BDD, a evolução
BDD é técnica de desenvolvimento ágil que visa integrar regras de negócios com
linguagem de programação, focando o comportamento do software. Além disso, pode-
se dizer também, que BDD é a evolução do TDD. Isto porque, os testes ainda orientam
o desenvolvimento, ou seja, primeiro se escreve o teste e depois o código.

O foco em BDD é a linguagem e as interações usadas no processo de desenvolvimento

de software. Desenvolvedores que se beneficiam destas técnicas escrevem os testes
em sua língua nativa em combinação com a linguagem ubíqua (Ubiquitous Language).
Isso permite que eles foquem em por que o código deve ser criado, ao invés de
detalhes técnicos, e ainda possibilita uma comunicação eficiente entre as equipes de
desenvolvimento e testes.

Linguagem Ubíqua: é uma linguagem estruturada em torno do modelo de domínio e usada por todos
os membros da equipe para conectar todas as suas atividades com o software. Numa equipe de
desenvolvedores são: os jargões técnicas, terminologias das discussões do dia-a-dia ou uma linguagem
incomum para pessoas de outros departamentos.

A linguagem de negócio usada em BDD é extraída das histórias ou especificações

fornecidas pelo cliente durante o levantamento dos requisitos. Alguns frameworks
utilizam o conteúdo das histórias escritas em um arquivo de texto como cenários para
os testes. Quando Dan North apresentou este conceito em 2003, ele sugeriu um
padrão para escrita destes arquivos.
Vantagens em usar BDD
Quando Dan North fala sobre BDD, ele sempre esclarece que o propósito não é anular
as práticas de TDD, muito pelo contrário, é adicionar a elas uma série de outras
vantagens, dentre as quais se podem listar:

• Comunicação entre equipes: na maioria das empresas de desenvolvimento de

software é difícil fazer com que desenvolvedores e testadores trabalhem em conjunto
para atingir um objetivo. BDD possibilita esta integração porque os testadores podem
escrever os cenários de testes para os desenvolvedores implementarem;

• Compartilhamento de conhecimento: com desenvolvedores e testadores

trabalhando juntos, ao longo do tempo, um irá transferir o seu conhecimento para o
outro, criando assim uma equipe multifuncional;

• Documentação dinâmica: algumas equipes ágeis afirmam que não documentam o

sistema porque a manutenção destes artefatos é custosa. Usando os frameworks de
BDD estes artefatos são gerados dinamicamente sem nenhum esforço adicional.
Alguns, inclusive, geram relatórios em formato HTML, o que irá facilitar uma consulta
posterior;

• Visão do todo: Fergus O’Connell, em sua obra “How to Run Successful High-Tech
Project-Based Organizations” (Artech House, 1999), apresenta uma relação dos
principais motivos que levam projetos de software ao fracasso. O primeiro deles é: “os
objetivos do projeto não são bem definidos e compartilhados entre todos os
envolvidos”. Por este motivo, BDD sugere que os analistas/testadores escrevam os
cenários antes mesmo dos testes serem implementados, e desta forma os
desenvolvedores terão uma visão geral do objetivo do projeto antes de codificá-lo.

Não restam dúvidas de que desenvolver uma aplicação guiada por testes é uma prática
extremamente benéfica. O resultado é um código de boa qualidade, alta coesão e com
número reduzido de bugs, com isso proporcionando um prazo de validade longo e
manutenções mais baratas no futuro. No entanto, iniciar no mundo dos testes não é
nada fácil.

Fonte: https://www.devmedia.com.br/desenvolvimento-orientado-por-
comportamento-bdd/21127

O Product Backlog é uma lista de funcionalidades desejadas de um produto, ou seja, os

requisitos que um cliente espera receber ao final do projeto, descrito com sua própria
linguagem. O ponto central do Scrum é a criação do Product Backlog, é nele que o projeto
começa.
O Refinamento do Product Backlog geralmente ocorre em:

 Nível Geral (compartilhado entre todas as equipes)

 Nível Equipe
 Nível Multiequipes

Refinamento Geral do Product Backlog

As regras do LeSS levantam as questões: como decidir quais as equipes são

suscetíveis de implementar os itens? Há problemas de escala como:
entendimento comum, coordenação, trabalho comum, estimativas alinhadas
e equilíbrio entre especialização e agilidade.
Uma sessão de PBR Geral aborda todos estes itens. Em resumo, realize uma
reunião de PBR Geral com os representantes das equipes antes das sessões
de PBR das equipes individuais, explore quais equipes poderão trabalhar em
cima de quais itens, e aumente o aprendizado e o alinhamento. Os
participantes incluem o Product Owner, especialistas no assunto, e tanto
todos os membros de todas as equipes quanto um par de representantes de
cada equipe. Representantes são geralmente preferidos, para manter a
reunião menor e não ter todos em mais uma reunião, embora exista um
custo com transferência e dispersão de informação.
Faça o seguinte:

 Divida grandes itens

 Faça uma análise bem simples do item para obter uma compreensão
básica
 Estime itens
 Identifique itens relacionados com trabalho compartilhado, trabalho
comum ou coordenação

Refinamento do Product Backlog - Nível

Equipe

Quando um item vai claramente ser feito por somente uma equipe e não terá
muita relação com outros itens, então o Refinamento do Product Backlog
será feito da mesma forma que uma única equipe Scrum. A equipe faz o
refinamento, de preferência em conjunto com os usuários/clientes/partes
interessadas e informe o Product Owner sobre as mudanças (divisões, novas
estimativas) no Product Backlog.

Refinamento do Product Backlog - Nível

Multiequipes

PBR Multiequipes ocorre quando mais de uma equipe literalmente está na

mesma sala ao mesmo tempo fazendo PBR. Os participantes incluem
especialistas no assunto, e tanto todos os membros de todas as equipes
quanto um par de representantes de cada equipe.
Qual a diferença do PBR Geral? O PBR Geral inclui a participação de todas as
equipes, mas um PBR Multiequipes pode envolver somente poucas equipes
(ex: duas equipes). Além disso, é mais provável que todos os membros
participem, em vez de representantes.
Realizar o PBR Multiequipe aumenta o conhecimento compartilhado e
explorar as oportunidades de coordenação quando um grupo de equipes
estão trabalhando em itens ou assuntos fortemente relacionados.
Fonte: https://less.works/pt/less/framework/product-backlog-
refinement.html
O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em
um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base
nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será
necessário para completar as várias funcionalidades.

O Product Owner é a pessoa que define os itens que compõem o Product Backlog e os prioriza
nas Sprint Planning Meetings. O Scrum Team olha para o ProductBacklog priorizado, seleciona
os itens mais prioritários e se compromete a entregá-los ao final de um Sprint (iteração). Estes
itens transformam-se no Sprint Backlog.

O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável por remover
quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões. O papel
de Scrum Master é tipicamente exercido por um gerente de projeto ou um líder técnico, mas
em princípio pode ser qualquer pessoa da equipe.