Palestra sobre BDD na UFSC - Universidade Federal de Santa Catarina. Talk sobre como é a utilização do BDD dentro de uma grande empresa de Software, a Softplan!

1. BDD – Behavior Driven Development
Allan Rett Ferreira – MBA, SAFe Agilist, SAFe PMPO
Allan Rett Ferreira
Utilizando BDD para análise de negócio
e desenvolvimento de projetos

3. Cenário Atual

4. Somente eu
posso fazer!

5. Documentação

6. Valida ai!

7. e no final...

8. Como é possível melhorar?
BDD

9. O que é o BDD
Behavior Driven Development – Desenvolvimento orientado ao
comportamento
É uma técnica de desenvolvimento ágil que estimula a
COLABORAÇÃO e COMUNICAÇÃO entre os participantes do
projeto: cliente, DEVs, gestores, QAs, pessoas não técnicas e de
negócios
Linguagem natural
Foco no COMPORTAMENTO do Sistema
Documentação única entre os participantes do projeto

10. Composição do BDD
Funcionalidades que serão desenvolvidas
Exemplo:
Cadastrar Usuário
Emitir Relatório
User Stories
Features
Critérios de Aceite
Cenários

11. Descrições simples de uma funcionalidade
Promover um diálogo, uma conversa
Resultado – É o que o ator espera que
aconteça ao realizar a ação. Também pode
ser visto como justificativa
Como um
<PAPEL>
eu
posso/gostaria/devo
<FUNÇÃO>
para/de
<RESULTADO para o
NEGÓCIO>
Papel – É o interessado na funcionalidade
Ação/Função – É o que o ator quer fazer.
Utilizando aquela ação ele espera alcançar um
objetivo dentro do sistema
User Stories

12. Critérios de Aceite
Exemplo:
Somente colaboradores que informaram o CPF podem ser cadastrados
Os Critérios de Aceite são representados por uma lista de itens de negócio
que expressam formas de usar a funcionalidade implementada em uma
US.
O objetivo dessa lista é validar se a Feature foi implementada de
acordo com o que o analista/cliente deseja.

13. Cenários
Os cenários descrevem as ações que serão aferidas e testadas. Eles devem conter passos
lógicos e simples de como obter um resultado específico a partir de uma sequência de
ações.
Dado que – São as pré-condições para executar o cenário
Quando – O que eu quero realizar, passos do cenário
Então – É o resultado esperado pela execução do cenário

14. GHERKIN

15. Papéis no BDD Analista de Teste
Documentação do
comportamento
Validação do comportamento
Levantamento dos cenários de
teste
Validação de escrita/qualidade
Analista de Negócio
Levantamento das necessidades e
funcionalidades
Levantamento das regras de negócio
Escrita das User Stories
Escrita dos critérios de aceite
Documentação do comportamento
Validação do comportamento
Levantamento dos cenários de teste
Validação de escrita/qualidade
Desenvolvedor
Implementa as features do BDD
Levantamento dos cenários de teste
Validação do comportamento
Validação de escrita/qualidade

21. 3 semanas = 16 Funcionalidades / 80 Cenários

22. Acompanhamento

23. Esforço
Economia de 92%de
esforço a cada versão
Economia de 7h de
trabalho homem/hora a
cada versão
80 CENÁRIOS
Teste manual Teste automatizado (CI
GitLab)
7 Horas* 36 minutos

24. Benefícios
Melhor entendimento da demanda, sem dúvidas do que deve ser feito
Pequenas reuniões (feature review) para validação das features
Melhora da comunicação entre todos participantes do projeto
Definição do comportamento do sistema, por meio de exemplos reais
Para o analista de negócio é uma VALIDAÇÃO de toda a análise, pois ajuda o
analista a verificar furos de negócio e furos na sua especificação
Medição do progresso do projeto através das features implementadas
Foco da equipe na resolução do problema e não em testes regressivos

25. Dificuldades
Curva de
aprendizado (em
média 2 semanas)
Falta/Dificuldade na
padronização da
escrita - Gera
retrabalho

26. FERRAMENTAS

27. Pickles
http://www.picklesdoc.com/

28. Ferramenta para escrita de cenários de testes de aceitação
no formato BDD (Dado/Quando/Então);​
Utiliza a linguagem Gherkin (linguagem natural/palavras
chaves).

29. Capybara (Ruby)
Framework de automação de testes em
aplicações web, open-source e escrito em Ruby
(Baseado no Selenium);
Interpreta os cenários escritos em BDD
(Cucumber);
Realiza ações do usuário no front-end.

31. Kanban

32. O BDD nos
permitiu este
final!!!

33. Evolução do BDD na Softplan
Comportamentos de APIs do sistema são desenvolvidos com apoio do BDD
Mantém a qualidade do código a cada geração de versão
User Stories e critérios de aceite descritos e planejados em ferramenta interna
Melhora da integração de novas pessoas ao negócio e ao sistema
Faz parte do processo de desenvolvimento das equipes
Utilizado como documentação junto com protótipos

36. Obrigado!
http://bit.ly/bdd-ufsc-2019