1ª Edição

BEHAVIOR
METODOLOGIA &
PRODUTIVIDADE

Driven Development Este conteúdo é de propriedade intelectual do Santander Tecnologia,

seu uso indevido fere as políticas de confidencialidade do banco.

Behavior-driven development é sobre implementar uma

aplicação através da descrição de seu comportamento
pela perspectiva de seus stakeholders CO M O F U N C I O N A O PR O C E SSO B D D
Dan North

D EFINIÇ ÃO
O BDD (Behavior-driven development - Desenvolvimento
Orientado por Comportamento) é uma técnica para
desenvolvimento de software, que visa descrever comportamentos
e integrar regras de negócio com a linguagem de programação,
focando no comportamento do usuário do sistema, ou seja, nas
ações que serão realizadas no sistema.

Essa técnica possibilita aprimorar o desenvolvimento de software

e estimula a colaboração entre todas as partes envolvidas no
projeto. Isso ocorre pela estrutura do BDD ser baseada em uma
linguagem simples e que possibilita um entendimento comum
entre todos os integrantes do time.

Os testes são escritos sem utilizar linguagem técnica, com foco

no comportamento do sistema, onde primeiramente os cenários
de testes são descritos para então escrever os testes em si.

O processo de BDD é dividido basicamente em 3 partes: estória

de usuário, funcionalidade e cenários, sendo que seu registro deve
ocorrer de maneira colaborativa entre os envolvidos - Negócio,
E STRUT URA
Desenvolvimento e QA.
Cenário de Teste: (objetivo do cenário)
DADO que (contexto inicial, entrada do teste)
E (contexto adicional se necessário)
S E MÂNTI C A DO B D D - E S C R I TA QUANDO (um evento ocorre, ação)
D E T ESTE S FUNCI O NAI S E (ação adicional se necessário)
ENTÃO (resultado esperado da ação)
A linguagem de negócio usada em BDD é extraída das estórias de usuário ou
especificações fornecidas pelo cliente durante o levantamento dos requisitos E (outro resultado esperado se necessário)
como cenários para os testes.

Recomenda-se que as estórias de usuário utilizem o modelo de escrita BDD

para descrever o comportamento. Definir critérios de aceite torna o processo
de escrita da estória mais simples, criando a possibilidade de serem usados
como base para testes de aceitação.
A partir dos critérios de aceite são elaborados os cenários de testes. Esses
contêm os requisitos e critérios de aceite do comportamento do sistema.
Os cenários de testes descrevem o que a funcionalidade precisa ter para ser
iniciada, o que ela fará em seguida e quais serão os resultados após a sua
execução.
Os cenários de testes são regidos por três palavras básicas que definem
o corpo da linguagem: Dado (Given), Quando (When) e Então (Then).
É possível também utilizar o termo “E”, se necessário incluir uma
segunda condição ao cenário. Cada bloco de cenário deve descrever um
comportamento, e os blocos devem ser encadeados para que juntos
formem um fluxo de negócio.

E X EMP LO DE E SPE C I F I C AÇ ÃO
DE CENÁ RI O DE TE ST E COM BD D
Estória de Usuário: Cenário de Teste 02: Filtro de consulta.

Como Assistente de atendimento Dado que A opção Histórico de Pagamentos esteja apresentada na tela.
Quero efetuar a consulta analítica de histórico de pagamentos - Quando Clicar no link da mesma.
PAGSAL Então Deverá ser apresentado na tela, o filtro com as opções de pesquisa
Para atender à solicitação do cliente e o botão Buscar.
Funcionalidade: Consulta analítica de histórico de pagamentos –
PagSal. Cenário de Teste 03: Consulta por Período de Histórico de Pagamento.

Cenário de Teste 01: Opção no menu de funcionalidades. Dado que Selecionei as opções desejadas no filtro de Período.
Quando Clicar no botão Buscar.
Dado que Acessei a home de produtos cash, no produto Pagamento Então Deverá ser executado o recurso de consulta analítica de histórico
de Salários. de pagamentos.
Quando Selecionar um convênio na lista de convênios.
Então Deverá ser apresentado com link clicável no menu de
funcionalidades, abaixo do subtítulo Consultas a opção Histórico
de Pagamentos.

Observe no exemplo acima que já temos uma documentação que contém o critério de aceite com a regra de negócio, o contexto com
as pré-condições do teste, o cenário que será validado e qual o dado de entrada que junto com uma ação disparará um resultado que será
positivo ou negativo dependendo do critério de aceite.

As boas práticas de escrita de BDD iniciam-se com a escrita dos critérios de aceite pelo Product Owner. O QA (Quality Assurance), a partir
das estórias de usuário, deve refinar os critérios de aceite e criar os cenários de teste. Recomenda-se que esse refinamento seja refletido
nas estórias escritas pelo Product Owner.

Os critérios de aceite devem estar registrados na estória na ferramenta JIRA, bem como os cenários de testes devem estar registrados
na ferramenta HP-ALM.

BEN EFÍC I OS VA N TAG E N S

BDD oferece um nível de entendimento comum entre o time (product Interação — Ocorre uma interação mais direta entre os envolvidos no time,
owner, desenvolvedores e QAs), já que podem utilizar uma linguagem mantendo assim a comunicação mais eficiente e permitindo ter testes mais
única e ubíqua. precisos.

A notação simples utilizada pelo BDD – Dado-Quando-Então – para os
testes de aceitação, facilita o entendimento dos envolvidos no projeto,
inclusive o cliente.
Maior facilidade por todos para visualizar o que está sendo
desenvolvido.
Minimiza a falha de comunicação entre stakeholders, cliente
e time de desenvolvimento do projeto.
Alta automatização de testes, facilidade para execução de testes de
regressão (aumento na qualidade).
Facilidade na manutenção dos cenários e scripts de teste.
O uso de boas práticas e padronizações estabelecidas propicia o reuso
de código para a implementação de novos testes automatizados de
qualidade.
Documentação dinâmica — A famosa documentação “viva”, aquela
construída durante o desenvolvimento, pode ser levada em consideração.
Os testes tornam-se a documentação do sistema escrita em uma linguagem
comum sendo documentados naturalmente, atrelando requisito ao código,
ou seja, o código é gerado a partir de uma descrição textual.
Testes baseados no comportamento — Os testes dizem como o sistema deve
se comportar, e não apenas os conceitos técnicos que os definem.
Compartilhamento de conhecimento — A integração entre o time promove
o compartilhamento de conhecimento e desenvolvimento mútuo. Todo
o processo de construção dos cenários permite que o time esteja alinhado
ao negócio e aos requisitos do sistema. O trabalho colaborativo, em
conjunto, permite sanar as dúvidas do time que surgem quando inicia-se o
desenvolvimento.

O S “ T RÊS A MI GOS” - OS PAP É I S BOA S PR ÁTI C A S PA R A I M PL E M E N TAÇ ÃO

N A ES CRI TA DO B D D D O B DD
QA

Elaboração de Envolvimento 
cenários de testes,
automatização de
QA nas estórias 
casos de testes Entendimento de usuário
dos requisitos de
negócio, contribuição
no seu domínio
(solução técnica e Coach
desenvolvimento
Escrita das do software Arquitetura
estórias de usuário, Ferramenta
Product Owner feedback BDD
Estórias de Entrega de
usuário seguindo critérios de aceite
Desenvolvedor padrão INVEST e de Testes na Sprint