1. BDD: Como quebrar
as barreiras de
negócios dentro do
time
ciandt.com
Andrelise Rafael Gonçalves

2. me.
Campinas - SPSanta Rita do Sapucaí - MG
ciandt.com

3. ciandt.com
me.
● 2012 - Engenharia de
Computação
● 2016 - MBA em Engenharia
de Software Orientado à
Serviços (SOA)

4. me.
ciandt.com

5. Principais Problemas nas Entregas do Projeto
ciandt.com
Falta de planejamento
Prazos arrojados
Alterações de escopo
Falta de comunicação

6. Principais Problemas nas Entregas do Projeto
ciandt.com

7. Principais Problemas nas Entregas do Projeto
ciandt.com

8. TDD - Test Driven Development
ciandt.com

9. TDD - Test Driven Development
ciandt.com
Desenvolvimento Orientado a Testes (TDD) É um processo de
desenvolvimento de software que consiste em criar um código que teste se o
código real do projeto funciona como deveria.

10. ciandt.com
TDD - Test Driven Development
Escrevemos um Teste que
inicialmente não passa (Red)
Adicionamos uma nova
funcionalidade do sistema
Fazemos o Teste passar
(Green)
Refatoramos o código da nova
funcionalidade (Refactoring)
Escrevemos o próximo Teste

11. BDD - Behavior Driven Development
ciandt.com

12. Dan North: Originador do BDD
ciandt.com
[Slide title]

13. “Eu era um fã da programação neurolinguística, então pensei que
tentaria um exercício linguístico para soltar a palavra "teste"
inteiramente. Isso me levou a pensar: se eu não estiver usando a
palavra" teste "em qualquer lugar, qual palavra devo usar? “
“Comecei a dizer: não estamos escrevendo testes para isso, estamos
escrevendo exemplos.” “E então estávamos tentando descrever o
comportamento do código antes que ele realmente existisse e, em
seguida, faça com que o código do aplicativo se comporte dessa
maneira.”
Dan North
ciandt.com

14. BDD - Conceito
ciandt.com

15. BDD - Principais Benefícios
ciandt.com
● Pode ser rastreado diretamente aos objetivos do negócio.
● Priorização eficiente: as características críticas para o negócio são entregues
primeiro.
● Todas as partes têm uma compreensão compartilhada do projeto e podem
estar envolvidas na comunicação.

16. BDD - Principais Benefícios
ciandt.com
● Uma linguagem compartilhada assegura a todos (técnicos ou não) uma
visibilidade completa da progressão do projeto.
● Design de software resultante que coincide com o existente e que suporta as
necessidades futuras do negócio.
● Melhoria do código de qualidade, reduzindo os custos de manutenção e
minimizando o risco do projeto.

17. BDD - Principais Abordagens
ciandt.com
Primeira abordagem
É a prática de usar exemplos escritos em linguagem onipresente para
ilustrar comportamentos (como os usuários irão interagir com o produto).
Segunda abordagem
É a prática de usar esses exemplos como base de testes automatizados.
Além de verificar a funcionalidade para o usuário, isso garante que o sistema
funcione conforme definido pelo negócio ao longo da vida útil do projeto.

18. BDD - Principais Abordagens
ciandt.com
Exemplo ruim: Vamos cadastrar todo o estoque da empresa para aplicar
desconto
Bom exemplo: Vamos realizar o cadastro de todos os produtos no estoque
da empresa a fim de conceder descontos nos produtos com etiquetas de
cores específicas

19. BDD - Mapeamento de Impacto
ciandt.com
O Mapeamento de Impacto é uma técnica que ajuda você a esboçar todas
as formas alternativas para alcançar seu objetivo decidido, analisando o
comportamento dos usuários. Assumimos que o software não pode atingir os
objetivos comerciais por conta própria. A única maneira de o software nos
aproximar do objetivo é suportar comportamentos humanos específicos.

20. BDD - Mapeamento de Impacto
ciandt.com
O Mapeamento de Impacto é uma técnica muito simples construída em
cima do mapeamento mental convencional, com uma ligeira rotação. Um mapa
de impacto tem quatro níveis distintos que consiste no objetivo comercial, um ou
mais atores, um ou mais impactos e uma ou mais maneiras de suportar ou
prevenir esses impactos.

21. BDD - Mapeamento de Impacto
ciandt.com

22. BDD - Mapeamento de Impacto
ciandt.com
WHY?
Primeira pergunta a ser respondida: Por qual motivo o projeto deve existir?
No caso, qual o objetivo a ser alcançado com a criação do software.
WHO?
Quem são os atores envolvidos que podem ajudar a impactar diretamente
e/ou indiretamente o objetivo estabelecido no item anterior.

23. BDD - Mapeamento de Impacto
ciandt.com
HOW?
Para cada ator, deve-se identificar como ele pode contribuir para atingir o
objetivo central.
Perceba que a lista deve ser focada no negócio. É natural vir a vontade de
listar o que o ator quer ou começar a pontuar as features, porém esse não é o
objetivo do mapa de impacto.
WHAT?
E por fim, vamos identificar os entregáveis ao se perguntar o que cada um
dos atores para obter os resultados esperados.

24. BDD - Mapeamento de Impacto
ciandt.com

25. BDD - Planejamento focado em exemplos
ciandt.com
Compreender através de exemplos é uma das primeiras práticas de
aprendizagem que começamos como crianças para remover a ambiguidade
e fornecer contexto para o que estamos tentando entender. Então, por que
não podemos usar exemplos para remover a ambiguidade da nossa
discussão em software?

26. BDD - Planejamento focado em exemplos
ciandt.com
Cadastro de Produtos para Inventário
Produtos com etiquetas de cores pretas devem possuir desconto de 50%
Produtos com etiquetas de cores azul devem possuir desconto de 20%
Produtos com etiquetas de cores vermelha não devem possuir desconto.

27. BDD - Planejamento focado em exemplos
ciandt.com
Você pode usar essas informações para oferecer um recurso de
trabalho? Claro que você pode! Mas quais são as chances de você ter errado
ou de que não compreendeu o que essas regras significam? Por exemplo,
essas regras não especificam deixam claro caso não houver produtos de
etiquetas preta ou azuis. Como lidar com estas situações?

28. BDD - Planejamento focado em exemplos
ciandt.com

29. BDD - Linguagem Ubíqua
ciandt.com
O idioma ubíquo é uma linguagem criada por desenvolvedores e
negócios para discutir recursos e conversar efetivamente em exemplos. Não
é uma linguagem técnica, mas também não é uma linguagem comercial; é
uma combinação de ambos.

30. BDD - Linguagem Ubíqua
ciandt.com
A chave nos dois lados tornando-se eficaz para a comunicação conjunta
reside na sua capacidade de aceitar, até certo ponto, os pontos de vista e a
compreensão mútua. A linguagem ubíqua é parte integrante do BDD. É
quase impossível ser eficaz com exemplos sem se esforçar para um idioma e
entendimento compartilhados.

31. BDD - Gherkin
ciandt.com
Gherkin é uma linguagem que foi criada especialmente para descrições
de comportamento, ela tem a capacidade de remover detalhes da lógica de
programação e focar no comportamento que uma funcionalidade deve ter.
Um arquivo Gherkin é semelhante a um Caso de Uso, contém:
● Título da funcionalidade.
● Descrição da funcionalidade.
● Cenários, compostos por uma seqüência de passos, que descrevem uma
interação entre um usuário e o sistema.

32. BDD - Dado, Quando e Então
ciandt.com
Dado
O objetivo dos dados é colocar o sistema em um estado conhecido
antes que o usuário (ou sistema externo) comece a interagir com o sistema
(nas etapas Quando).
Dado que [ Estado inicial do sistema ]
Dado que eu possua um produto no estoque

33. BDD - Dado, Quando e Então
ciandt.com
Quando
O objetivo desta etapas é descrever a ação-chave que o usuário executa.
Quando [ Ação a ser realizada no sistema ]
Quando o produto possuir etiqueta preta

34. BDD - Dado, Quando e Então
ciandt.com
Então
O objetivo de é observar os resultados. As observações devem estar
relacionadas ao valor/benefício da empresa na descrição do recurso. As
observações também devem estar em algum tipo de saída - isso é algo que
sai do sistema.
Então [ Coisas que o sistema deve fazer após a ação do Quando ]
Então devo aplicar o desconto de 50% em cima do valor original

35. BDD - O Analista de Negócio, o DEV e o Tester
ciandt.com
Um dos erros mais comuns que as equipes cometem ao começar a
trabalhar com BDD é dar essa responsabilidade a uma pessoa é suficiente. (
Geralmente o Tester ou o Analista de negócio)

36. BDD - O Analista de Negócio, o DEV e o Tester
ciandt.com
O BDD é um processo altamente colaborativo. Falar em exemplos
exige não só mais de uma pessoa ter essa conversa, mas requer diferentes
perspectivas e experiências para ser eficiente.
Uma das principais idéias por trás do BDD é que nenhuma pessoa possui
a resposta completa ao problema. Todos os ângulos podem ser cobertos se
você reunir os insights de uma pessoa de negócios, um desenvolvedor e um
testador.

37. BDD - O negócio, o DEV e o Tester
ciandt.com
Os papéis de negócios, como um proprietário de produto ou analista de
negócios, permanecem no domínio do valor comercial e avaliação de risco;
sua visão e entrada são extremamente importantes se você quer entregar o
software que importa.
Os desenvolvedores, em sua maioria, permanecem no chamado espaço
de "solução". A sua contribuição lhe dará um contexto inestimável em quantos
detalhes o recurso deve ter para ser implementável.
Os testadores geralmente representam o espaço do "problema"; eles
vêem falhas acontecendo no sistema mesmo antes do início do
desenvolvimento.

38. Referências
ciandt.com
● https://dannhttp://www.eduardopires.net.br/2012/06/ddd-tdd-bdd/orth.net/introducing-bdd/
● https://dannorth.net/whats-in-a-story/
● https://inviqa.com/blog/bdd-guide
● http://behaviour-driven.org/
● https://www.thoughtworks.com/pt/insights/blog/3-misconceptions-about-bdd

39. ciandt.com

40. Contatos
ciandt.com
br.linkedin.com/in/andrelise
andrelise.rafael@gmail.com

41. Thank you!
ciandt.com