No mundo da qualidadE de software, o termo BDD (Behavior

Driven Development) ou Desenvolvimento Orientado ao

Comportamento é muito conhecido como uma das principais
maneiras de se escrever cenários para realizar automação de
testes. Até mesmo nas principais plataformas de estudo, ao
buscar sobre o assunto para o aprendizado, nos deparamos com o
termo atrelado a automação de testes.

Alguns QAs inclusive acreditam que o BDD é a escrita de cenários

após as funcionalidades serem desenvolvidas. Outros entendem
que não é possível (em contextos de desenvolvimento ágil)
escrever cenários de teste de outra forma. O certo é que nenhuma
dessas narrativas está totalmente correta e para desmistificar
esses pontos temos que voltar um pouco no tempo...
 EVOLUÇÃO DO PROCESSO DE DESENVOLVIMENTO

Em meados da década de 70 tivemos um avanço

tecnológico. Os computadores com poder de
processamento gigantesco auxiliaram na
automatização de processos que antes eram feitos
manualmente. Criar um software naquela época era
complexo a nível técnico, mas não exigia um processo
tão robusto. Na imagem temos a evolução dos
processos de desenvolvimento de software, dando
destaque para a metodologia Waterfall (em cascata)
e a Agile (Metodologia Ágil).

O modelo em cascata segmenta cada fase do desenvolvimento de software do início ao fim do

projeto. Com isso um software tinha um documentação robusta que se atentava em prever todas as
funcionalidades no início do projeto. Quando a documentação era finalizada, a etapa de
desenvolvimento e, posteriormente, os testes eram inseridos. Com o passar dos anos, entendeu-se
que a partir da concepção de um ideia um produto digital deveria estar atrelado a ela e, portanto,
vários conceitos como MVP (Minimum Viable Product ou Produto Mínimo Viável) estavam se
tornando cotidianos. A construção do software poderia então iniciar sem ter todos os requisitos
esclarecidos. Esse tipo de desenvolvimento começou a necessitar de um processo mais ágil, onde o
foco não era mais na documentação e sim no desenvolvimento e testagem rápidos.

ENTENDENDO UM
POUCO DO TDD
Escrever o

Agora que temos um contexto teste para falhar

histórico de processos, precisamos
entender como surgiu o BDD e para N° de ciclos
isso, é necessário falar sobre TDD
(Test Driven Development ou
Desenvolvimento Orientado por
Testes).

TDD
O TDD é uma parte da metodologia Escrever o
XP Sendo utilizado Em diversas Refatorar
código para
outras metodologias, além de poder quando passar o teste
ser utilizado livremente. Criado por necessário
Kent Beck na metade da década 90,
tem foco em minimizar e antecipar
os bugs na cadeia de
desenvolvimento. Os ciclos do TDD
são ilustrados na imagem ao lado.

O TDD é focado em testes, baseando-se em

um loop de ciclos, onde cada funcionalidade
do sistema tem a codificação de um teste
criado que deve quebrar em um primeiro
momento. Assim que a codificação da
funcionalidade for finalizada o teste deve ser
rodado. Caso o teste não passe é necessário
realizar a refatoração até que venha a ser
concluído com sucesso. O intuito do TDD é
fazer com que o desenvolvedor escreva um
código de melhor qualidade.

O grande problema, como vimos

anteriormente, é que havia um gargalo nesse
processo e na metodologia. A falta de um
documento que integrasse todo o time de
desenvolvimento e que deixasse claro o que
era necessário testar fazia com que as
validações ficassem pobres e muitas vezes o
entendimento do que era testado não era claro
para todos. 

COMO O BDD SE ENCAIXA

Em 2003, para suprir uma certa deficiência

no modelo TDD, visando dar mais foco na Escrever o

teste para falhar

clareza do escopo a ser testado aproximando

assim a área de negócio com a área técnica,

foi criada a metodologia de desenvolvimento Escrever

N° de ciclos

o teste BDD
chamada BDD. O BDD nasce então

basicamente para que seja possível escrever

um cenário de testes em padrão específico.

TDD
Porém, esta técnica vai muito além da escrita

de cenários, por ser descrito em uma sintaxe Escrever o

código para
que envolve linguagem natural e lógica. Refatorar

quando passar o teste

Neste sentido, se faz necessário entender
necessário

que o BDD é uma espécie de contrato e

forma de comunicação entre todos os

integrantes da equipe de desenvolvimento

relativos aos comportamentos esperados

do sistema. Veja uma ilustração da

metodologia BDD de desenvolvimento:

UTILIZAÇÃO DE BDD EM OUTRAS METODOLOGIAS ÁGEIS

Com o passar dos anos, empregou-se adicionalmente o BDD em outros contextos, metodologias
e escopos de teste na área de QA, com o intuito de minimizar a escrita de casos de testes
tradicionais (por vezes muito verbosos e de difícil manutenção) e facilitar o desenvolvimento
de testes automatizados de software. Para encaixar o BDD em um processo de
desenvolvimento ágil como o SCRUM, temos um exemplo de uma aplicação sem a dependência
do TDD, conforme ilustrado abaixo.

O PO estrutura um QA escreve Funcionalidade

roadmap de features os cenários é entregue

01 02 03 04 05

Os cenários guiam o
Equipe elabora desenvolvimento e os
requisitos testes automatizados
 Esse processo de desenvolvimento de software usando

SCRUM se dividiu em 5 etapas, sendo elas:

Estruturação de roadmap de funcionalidade:


Nessa etapa o PO (Product Owner ou Dono do Produto) questiona e analisa os desejos dos

1 stakeholders e monta o roadmap de funcionalidades que serão implementadas nas etapas

seguintes do desenvolvimento;

Elaboração dos requisitos:


Nesta parte que o BDD se encaixa, os requisitos são debatidos em uma reunião que é chamada

2 de “Os três Amigos”, onde PO, QA e UX (isso não é uma regra) se juntam para identificar cenários

chaves, regras de negócio e requisitos que devem estar corretos no momento da codificação;

Escrita dos cenários:

3
Geralmente o QA fica responsável pela escrita dos cenários levantados no passo 2. A linguagem

adotada no BDD é o Gherkin, que auxilia o entendimento dos comportamentos para todo o time;

Desenvolvimento e testes automatizados:

Os cenários descritos na etapa 3 devem guiar os desenvolvedores na codificação, garantido que

4 os mesmos estejam em conformidade. Utilizamos o recurso do BDD para descrever os testes

automatizados, principalmente os cenários de testes regressivos;

Entrega:

5
Assim que todas as etapas forem entregues, temos uma funcionalidade testada e coberta,

garantindo o emprego do BDD de uma maneira coerente.

 Palavras-Chaves: Dado (Given) 

O “Dado” seria basicamente as pré-condições do cenário.

Obs: O tempo verbal para esse passo é o passado.

BDD E SEUS PADRÕES Ex: Dado que preenchi

cliquei

selecionei

Palavras-Chaves: Quando (When) 

O BDD é uma sintaxe de documentação no O “Quando” serve para descrever as ações chave que o
usuário executa, resumidamente seria qualquer ação de
formato Gherkin que usa palavras chave interação do usuário com o sistema.

baseadas em linguagem natural, que segue Obs: O tempo verbal para esse passo é o presente.

uma lógica de escrita dando suporte técnico Ex: Quando preencho

clico

para o time fazendo com que todos seleciono

entendam o que está sendo desenvolvido e

validado. O Gherkin por sua vez é uma Palavras-Chaves: En o ( hen) 

tã T

O “Então” visa mostrar as sa das, os resultados das ações

linguagem natural de escrita que auxilia no í

executadas, basicamente os resultados esperados.

entendimento dos cenários descritos para Obs: O tempo verbal para esse passo é o t ro.
fu u

todas as partes interessadas do projeto (PO, Ex: Então o botão contato estará vis ve
‘ ’ í

Então a mensagem vendedor inválido deverá ser exibid

l

desenvolvedores, testadores, analistas etc.) ‘ ’ a

devido a sua simplicidade. Nestes casos, os Palavras-Chaves: E (And) 

cenários devem ser descritos para gerar uma O “E“ é um complemento para a não utilização repetida dos
passos “Dado“, “Quando” e “Então“ nas linhas subsequentes.

documentação viva e com valor para o Ex: Dado que tenha um usuário previamente cadastrado na base
negócio. Ao lado, seguem palavras-chave
;

E cliquei no cone do sistema

í ;

com exemplos de descrição de cenário.

Quando preencho o campo login com xxx
E preencho o campo senha com 'yyy';

‘ ’;

E clico no botão submit

' ';

Então a tela inicial deverá ser exibida ;

E o nome do usuário deverá aparecer no t tulo da págin í a

MANEIRAS DE DESCREVER CENÁRIOS DE TESTES COM BDD

Existem dois formatos para escrever um BDD. Ambos exercem o mesmo teste, porém os dois
tem suas particularidade e dificuldades de implementação no processo, são eles:

ESCRITA IMPERATIVA ESCRITA DECLARATIVA

Essa escrita preocupa-se em descrever como que o

cenário deve ser realizado, através de um passo a Essa escrita se preocupa com o que o teste
passo bem detalhado do que deve ser feito em todas deve fazer, expressando o seu comportamento
as etapas do teste, suas pré-condições e validações. e não detalhando o grupo de passos.
 QUAL A ESCRITA MAIS INDICADA A SE USAR?

Alguns profissionais de qualidade ainda

descrevem os seus cenários de maneira
imperativa, o que não é indicado nestes casos por
alguns motivos. Para elucidar melhor vamos
comparar a descrição de cenário imperativa com a
escrita de um caso de teste tradicional.
 A manutenção da documentação fica

1
Qualquer semelhança não é complexa, visto que ao alterar qualquer

mera coincidência, pois tirando elemento em tela o cenário deve ser alterado;

o padrão de palavras-chave

2
essas duas escritas são iguais. A descrita verbosa dificilmente é lida por um

Portanto, o emprego de uma desenvolvedor no momento da codificação;

técnica para agilizar o processo

3
de escrita sendo aplicado de Não é intuitiva a ponto de sabermos o que o

uma maneira tradicional não cenário faz sem ter que ler diversos passos;

traz total benef ício ao qual o

4
BDD possa ser vislumbrado. A manutenção da documentação fica mais

Alguns dos pontos negativos f requente, às vezes o cenário é descontinuado;

desse tipo de escrita são:

5 Dificulta na clareza de qual é o escopo do teste.

Já a escrita declarativa tem o foco em expressar o que o cenário deve fazer, ou

seja, o seu comportamento. Se desmembrarmos novamente o termo BDD

(Behavior Driven Development ou Desenvolvimento Orientado ao

Comportamento), podemos ver que a escrita está ligada diretamente com o

propósito do BDD, que é desenvolver funcionalidade baseado no

comportamento desejado. Algumas das vantagens de escrever desta forma são:

1
Cenários mais rápidos de serem descritos;

A chance de aderência dos desenvolvedores em ler os cenários neste

2 formato é maior;

Mudanças em tela não alteram a documentação descrita.

3 Apenas mudanças de comportamentos que vão exigir uma refatoração.

4 Escopo de teste claro;

5
Todo time com o entendimento rápido da cobertura de testes.
É importante salientar que a equipe de QA deve estar envolvida
em todo o processo de desenvolvimento e não somente em uma
das etapas, e que ela não é a única responsável pela qualidade. No
entanto, deve ter um olhar analítico para identificar possíveis
gargalos não somente no produto, mas também no processo.

Portanto, quando descrever os seus cenários de teste pense no

processo e nas ferramentas que se está utilizando e se as
mesmas fazem sentido no contexto a qual estão inseridos.

Esse é um dos exemplos em que um profissional de QA pode se

basear. Apenas alterando o momento da escrita dos cenários e a
forma como se escreve já podemos ter um ganho considerável na
qualidade e velocidade do projeto, além de evitar bugs antes da
fase de desenvolvimento, afinal como vimos neste ebook, BDD vai
muito além da escrita de cenários de teste.

(51) 9 9233-8382 atendimento@testingcompany.com.br Matriz | Pedro Adams Filho, 5857 - Centro, NH - RS