Garantir a qualidade de um produto complexo antes de colocá-lo em produção é pré requisito. Mas como fazer isso em um cenário com centenas de regras de negócio diferentes e específicas por UFs, municípios e clientes? E como garantir que todos os membros do time tenham capacidade de testar, conheçam as regras e se sintam seguros? Nessa palestra, vamos demonstrar como usamos a técnica de BDD com linguagem Gherkin na nossa empresa para fomentar o uso de uma linguagem ubíqua e gerar uma comunicação assertiva entre o Dev Team e o PO. Este case permitiu o compartilhamento de conhecimento, garantindo que as regras e cenários de negócio mais críticos fossem entendidos e automatizados com SpecFlow.
TDC SP 2019 - Facilitando a Vida do PO e do Time com BDD
1. _ X
+
+
+
+
Facilitando a Vida do PO e
Dando Segurança para o Time
de Desenvolvimento com o
uso do BDD
+
+
+
+
G L E I C A R E I N E R T
R A F A E L T A R G I N O
2. SOBRE NÓS... _ X
+
R A F A E L T A R G I N O
G L E I C A R E I N E R T
+
Agile Coach
• Mestre em Engenharia da Computação - COPPE/UFRJ
• Professor de Pós na PUC-Rio
• Palestrante desde 2014 (TDC, SGRio, Agile Brazil)
• Organinzador do MeetUp Agile Beer
Scrum Master
• Bacharela em Ciências Contábeis - FURB
• MBA em Gestão Tributária – INPG
• Organizadora dos MeetUps Agile Beer e Mulheres
de Produto – Blumenau/SC
3. Falhas de Comunicação
Confusão entre o que foi
falado e o que foi
entendido
Bugs
Dificuldade do Time
em identificar erros
durante o
desenvolvimento
Estimativas erradas
O Time não tinha
segurança em estimar
Histórias Falhando
Sprints se passavam e
histórias se mantinham
Falta de Conhecimento
As regras de negócio
eram complexas e o
Time era novo
Desgaste
PO insatisfeito e todo o
Time sendo
influenciado
negativamente pelo
cenário
Apenas Analista de
Negócios testavam
Gargalo nas atividades,
pois apenas o Analista de
Negócios conseguia
testar de forma segura
Impactos
Correções apontadas
em regras refletiam
em outras de forma
indevida
PROBLEMAS
5. +
+B e h a v i o r D r i v e n
D e v e l o p m e n t
. . . o u . . .
D e s e n v o l v i m e n t o G u i a d o
p o r C o m p o r t a m e n t o
BDD
6. _ X
BDD
+
+
+
+
C O N C E I T O
“ B D D é s o b r e i m p l e m e n t a r
u m a a p l i c a ç ã o a t r a v é s d a
d e s c r i ç ã o d e s e u
c o m p o r t a m e n t o p e l a
p e r s p e c t i v a d e s e u s
s t a k e h o l d e r s ” .
( D a n N o r t h )
7. X_
É uma técnica de
desenvolvimento ágil
que visa integrar regras
de negócios com a
linguagem de
programação, focando
no comportamento do
software.
B D D
D e s e n v o l v i m e n t o G u i a d o
p o r C o m p o r t a m e n t o
O intuito é manter uma linguagem
estruturada onde todos os
membros do time possam
compreender a necessidade da
entrega. Para isso, é utilizado um
modelo de escrita, chamado
Gherkin.
8. GHERKIN
M O D E L O D E E S C R I T A
Linguagem 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.
Os cenários representam
exemplos concretos que
ilustram restrições de
negócio e são constituídos
de uma lista de passos.
Além de ser uma
especificação do negócio,
o cenário é também um
teste (comportamento).
E m r e s u m o : o s c e n á r i o s s ã o
e s p e c i f i c a ç õ e s e x e c u t á v e i s d o s i s t e m a .
9. +
+
+
+ _ X
GHERKIN
E S T R U T U R A
Os cenários são descritos em forma de pré-condições, eventos e resultados esperados
usando a sintaxe: Dado / Quando / Então, respectivamente.
Cenários simples
Título [...]
Dado que (Given) [...]
Quando (When) [...]
Então (Then) [...]
Cenários com mais condições
Título [...]
Dado contexto [...]
E [um pouco mais de contexto...]
Quando [eventos]
Então [resultado]
E [outro resultado ...]
11. _ XR E G R A S D E N E G Ó C I O x B D D
Tratar as regras de
negócio em um
repositório a parte e
escrever os cenários
relacionados
Utilizar os cenários
como forma de
explicitar as regras de
negócio
X
13. _ XR E G R A S D E N E G Ó C I O
C E N Á R I O I N I C I A L
14. +
+
+
+
+
X_
MUNDANÇA E APLICAÇÃO DO BDD
I N C E N T I V A D O R
P O
T I M E D E
D E S E N V O L V I M E N T O
S C R U M M A S T E R
15. _ XR E G R A S D E N E G Ó C I O
C E N Á R I O C O M B D D E L I N G U AG E M G H E R K I N
Título: C04 - Tomador Estabelecido Não Optante do
Simples Nacional - Sem Retenção
Dado que a empresa Tomadora é do tipo estabelecido não
optante pelo Simples Nacional
Quando solicitar uma nova declaração de nota de serviço
da modalidade Prestado
E não possuir imposto retido
Então o campo alíquota deverá ficar desabilitado
E o valor ser igual a 0
História:
Sendo um PRESTADOR ESTABELECIDO e OPTANTE DO
SIMPLES NACIONAL
Posso declarar um nota fiscal de SERVIÇOS PRESTADOS
Pois assim faço o registro do faturamento
16. X X X X
U S O D O B D D
BENEFÍCIOS
Facilmente
descobre-se a
falta de uma pré-
condição, ou o
esquecimento de
um resultado
esperado.
É uma forma de manter
uma documentação e
mapeamento do que
deve ser testado por
funcionalidade, mesmo
que quem execute a
atividade não tenha o
nível de conhecimento
de negócio exigido pelo
produto.
Documentação que
facilita a análise de
impactos, execução
do desenvolvimento
e testes.
Aumenta a
qualidade do
software como um
todo, uma vez que
serve para criar
testes e integrar
regras de negócios
com a linguagem
de programação.
+
18. _ X
AUTOMAÇÃO
+
+
+
+
F E R R A M E N T A S
O o b j e t i v o d e t e r u m a
f e r r a m e n t a q u e e x e c u t e a
l i n g u a g e m d o B D D / G h e r k i n é
a f a c i l i d a d e d e a u t o m a t i z a r
o s c e n á r i o s c r i a d o s , p o i s
e s t a t a n t o i r á v a l i d a r o
s o f t w a r e q u a n t o f o r n e c e r
u m a d o c u m e n t a ç ã o
a t u a l i z a d a , t é c n i c a e
f u n c i o n a l .
19. X_
Existem várias
ferramentas e
frameworks que dão
suporte ao BDD, de
acordo com sua
linguagem de
programação.
F E R R A M E N T A S
E x e m p l o s
SpecFlow
Cucumber
JBehave
Selenium
20. _ XA U TO M A Ç Ã O
S P E C F LOW Título: C04 - Tomador Estabelecido Não Optante do Simples Nacional - Sem Retenção
Dado que a empresa Tomadora é do tipo estabelecido não optante pelo Simples Nacional
Quando solicitar uma nova declaração de nota de serviço da modalidade Prestado
E não possuir imposto retido
Então o campo alíquota deverá ficar desabilitado
E o valor ser igual a 0
21. +
+
+
+ _ X
+
CONCLUSÃO
Comunicação
Melhora na comunicação entre desenvolvimento,
testes e a própria área de negócios com uma
linguagem ubíqua.
• O uso do BDD trouxe uma série de vantagens para todo o Time e
qualidade do produto
Confiança entre o Time Scrum
Com as regras de negócios atendidas, o Analista
de Negócio e PO voltaram a confiar no Time.
Histórias “Done!”
As estimativas melhoraram, fazendo com que a
performance do time aumentasse.
Compartilhamento de Conhecimento
Com a comunicação eficiente, a troca de
conhecimento passou a ser mais efetiva.
Documentação
O BDD faz com que exista uma documentação
atualizada do sistema.
Testes
Qualquer membro do Time pode testar e é
possível utilizar a automação para garantir
análise de impactos.
22. _ X
REFERÊNCIAS
+
+
+
+
•S p e c F l o w ( h t t p s : / / s p e c f l o w . o r g / )
•" G h e r k i n " - C o m u n i c a ç ã o a t r a v é s d e
u m v o c a b u l á r i o p e q u e n o e c o m u m ,
d i m i n u i n d o a d i s t â n c i a e n t r e o
n e g ó c i o e a e q u i p e d e T I – M a r c u s
V . M . G o m e s .
•U t i l i z a n d o B D D p a r a a n á l i s e d e
n e g ó c i o e d e s e n v o l v i m e n t o d e
p r o j e t o s - A l l a n R e t t F e r r e i r a
•B D D - A t é c n i c a q u e f a c i l i t a
e n t r e g a r s o f t w a r e q u e R E A L M E N T E
a t e n d e o n e g ó c i o – M a r c e l o N e v e s
23. +
+
+
+
+
PERGUNTAS?
O B R I G A D O ( A ) !
www.linkedin.com/in/gleica www.linkedin.com/in/rafaeltargino/
Quer saber mais sobre agilidade?
http://mentoriascrum.com.br
Notas do Editor
A ideia principal dessa apresentação é demonstrar o cenário e os problemas que estávamos tendo com um determinado time dentro da GovernançaBrasil. Dessa forma, listamos aqui alguns dos problemas que vínhamos tendo neste time...
(falar um pouco do contexto do time a partir desses problemas)
Comentar que a ideia partiu de um dos membros do próprio time de desenvolvimento... Que utilizava o BDD em projetos pessoais.
Dan North criou o BDD em 2003.
O PO e o analista de negócio tinham esta planilha que era composta por centenas de regras de negócios que deveriam ser validadas, porém o Time tinha dificuldade em cobrir todo este cenário. Isso envolvia várias pré-condições, regras, clientes específicos, etc.
O PO e o analista de negócio tinham esta planilha que era composta por centenas de regras de negócios que deveriam ser validadas, porém o Time tinha dificuldade em cobrir todo este cenário. Isso envolvia várias pré-condições, regras, clientes específicos, etc.
O PO e o analista de negócio tinham esta planilha que era composta por centenas de regras de negócios que deveriam ser validadas, porém o Time tinha dificuldade em cobrir todo este cenário. Isso envolvia várias pré-condições, regras, clientes específicos, etc.
O membro do time de desenvolvimento “incentivador” que já havia trabalhado com BDD expôs a prática para o PO e os demais membros do time e juntos começaram a escrever as regras de negócio utilizando a linguagem Gherkin, transcrevendo a planilha anterior.
Esse compartilhamento de informações e prática fez com que a comunicação ficasse ubíqua.
A partir dessa fase, os cenários começaram a ser criados assim, dentro da estrutura proposta.
Isso trouxe uma série de benefícios para todo o time:
Apresentar tudo o que foi demonstrado até o momento e falar sobre a automação que é a “cereja do bolo”. A partir da estrutura criada para os cenários com uso do BDD e Gherkin, seria possível automatizar os cenários já descritos, mantendo uma documentação “viva” das funcionalidades.
Direcionar o foco para a automação com SpecFlow.
No time em questão a linguagem de programação é C# então ficaria mais simples de trabalhar com o SpecFlow, já que este é um NuGet que se integra com o Visual Studio.
Utilizando o mesmo exemplo anterior, ao incluir as pré condições “Dado que”, “quando” e “então” o specflow dá a opção de criar automaticamente a estrutura para automação pela função “Generate Step Definitions” e basta trazer as classes que devem ser chamadas para cada pré condição.
Ao clicar sob a linha também é possível visualizar o código já indicado através da opção Go to Definition ou teclar F12.
O SpecFlow fornece ligação direta com o Test Explorer do Visual Studio, o que facilita a execução dos testes.