PROCESS

CLAN
Cenário tradicional

Analista de Analistas de testes

Devs
negócio
Cenário tradicional

Oportunidade para perda de informação

Risco de compreensão equivocada

Falta de clareza na descrição

E no fim...
(BDD)
“Behavior Driven Development é sobre implementar uma aplicação através da
descrição de seu comportamento pela perspectiva de seus stakeholders”

Dan North
O que é BDD?

O BDD é uma técnica de desenvolvimento Ágil que encoraja em um projeto de software a

colaboração entre:

Desenvolvedores

Setores de Qualidade

Pessoas não-técnicas (Negócio)

O que é BDD?

Documentação que vira teste e código

Linguagem Ubíqua

Foco no comportamento do sistema

É uma forma de todos falarem a mesma língua, a língua do negócio.

Os três amigos
Os três amigos

Dev, Negócios e QA

Juntos discutem features e desenham exemplos

Entendimento compartilhado
Composição BDD
Features

User Stories

Critérios de aceite

Cenários
 Features Stakeholder e analista discutem os
requisitos

Os requisitos são organizados em

User Stories funcionalidades (features)

Ex:
- Cadastrar usuário
Critérios de aceite - Emitir relatório

Cenários
 Descrição simples da funcionalidade.
Features
Como um < Papel >

Eu quero < Alguma necessidade >

User Stories Para que < Resultado para o negócio >

Ex:

Critérios de aceite
Como vendedor quero consultar o estoque de
determinado produto para oferecer a algum cliente

Cenários
 Features
Lista de itens de negócio que expressam
como usar a funcionalidade implementada

User Stories Validar se a feature foi criada de acordo

com o que cliente deseja

Critérios de aceite

Cenários
 Features
Ações que serão testadas de acordo com
os critérios de aceite

User Stories Escrita Gherkin

Critérios de aceite

Cenários
QA
Gherkin
Gherkin

Documentação viva
Linguagem criada para descrições de comportamento
Aproximação entre a área de negócio e TI
Estrutura

Funcionalidade
Cenário
Steps (Dado, Quando, Então, E, Mas)
Funcionalidade

Título
Breve descrição
Cenário

Deve conter o nome do cenário seguido

de steps

Cada funcionalidade pode ter um ou mais

cenários
Steps

Dado

Estado antes da interação com o sistema

Pré condição do sistema

Steps

Quando

Descrever a ação que o usuário executa

Descreve ações entre o usuário e o sistema

Steps

Então

Mostrar saídas

Resultados das ações executadas

Devem estar relacionada com o

valor/benefício do negócio
Steps

Visa complementar qualquer uma das

palavras chaves

Evita repetição das palavras chaves

Steps

Mas

Forma negativa de complementar as

palavras chaves

O que o usuário não deve receber

Na prática...
Vamos imaginar que estamos em uma plataforma de e-commerce

Área de negócio definiu que seja mostrado o preço combinado dos produtos no carrinho, adicionando
imposto de 20% em cima dos produtos e somando com o valor do frete .
Na prática...
Foram definidas as seguintes regras:

O imposto é de 20%
O frete para um carrinho de compras até R$ 10,00 é R$ 3,00
O frete para um carrinho de compras maior que R$ 10,00 é R$ 2,00
Na prática...
O que podemos entender por adicionar imposto?

O que acontece quando tivermos dois produtos, um com valor

menor que R$10 e outro de maior valor?
Na prática...

?
Na prática...
Na prática
Desta forma, nós e nossos stakeholders compartilhamos da mesma escrita em um formato
estruturado do projeto.

Tudo é baseado em uma conversa que tivemos juntos.

Isto é, na essência, o que o BDD é.

Gherkin

Boas práticas
Boas práticas

Não altere a estrutura padrão

Mantenha o padrão (Dado, Quando, Então)

Não repita essas palavras no mesmo cenário

Faça o uso de 'E'

Boas práticas

Seja mais comportamental do que

procedural

Não descreva o passo a passo do sistema

Descreva o comportamento
Boas práticas

Use Contexto

Remove o que está sendo repetido nos cenários, centralizando no contexto

Boas práticas
Sem contexto: Com contexto:
Boas práticas

Use tags
Use tags para filtrar, agrupar e executar cenários e funcionalidades específicas

ex:

@portal_rh @ec @hmp @dsp @pedido_online

Boas práticas
Use Esquema de cenário
Utilizado quando os cenários têm validações e resultados parecidos
Sem esquema de cenário: Com esquema de cenário:
E para finalizar...
BDD não é só escrever em Gherkin
BDD não é sobre usar Behave, Cucumber ou Specflow
BDD não é só para automatizar testes
BDD não é bala de prata
BDD é modo de pensar... E isso inclui gerência
BDD é foco na colaboração!
BDD Warriors

Objetivo
Exercitar o entendimento na prática sobre a criação de cenários utilizando a metodologia BDD
BDD Warriors

Cada jogador deve:

Pegar um tipo de ficha que irá representar suas

jogadas;
Colocar o seu peão/ficha no ponto zero do
tabuleiro;
Receber 5 cartas;
Decidir em grupo quem irá iniciar jogando;
BDD Warriors
O Primeiro jogador deve:

Jogar uma carta de qualquer cláusula (Dado, Quando, Então ou E);

Colocar uma ficha em cima da carta jogada;
Completar a descrição da cláusula jogada;
Andar com o seu peão o número de pontos descrito na carta jogada;
Comprar uma carta da pilha de compra (sempre possuir 5 cartas em mãos);
BDD Warriors

O próximo jogador deve:

Jogar uma carta que continue o cenário iniciado pelo primeiro jogador, ou pode iniciar um
novo cenário;
Colocar uma ficha em cima da carta jogada;
Completar a descrição da cláusula jogada;
Andar com o seu peão o número de pontos descrito na carta jogada;
Comprar uma carta da pilha de compra (sempre possuir 5 cartas em mãos);
BDD Warriors

Para um cenário estar completo, ele deve:

Conter uma carta de cada cláusula (Dado, Quando, Então e E), sendo a cláusula E opcional;
Conter apenas uma cláusula E;
Ex:
Dado que Alice é uma lobisomem
Quando o relógio estiver perto de meia noite
E for noite de lua cheia
Então Alice deve correr para caverna
BDD Warriors
Pontuação - Pontos por carta de cláusula
Os pontos são contabilizados de acordo com
cada carta jogada de cláusula (Dado, Quando,
Então ou E)

Pode valer 1 ou 2 pontos.

BDD Warriors EX:

Dado um vampiro - jogador 1

Então ele deve virar pó - jogador 2 Quando
Pontuação - Dois pontos for atingido por uma estaca - jogador 3

Cenário completo na ordem:

- É contabilizado 2 pontos para o jogador
que encerrar o cenário. Dado um vampiro
Quando for atingido por uma estaca. Então ele
deve virar pó.

Neste exemplo o jogador 3 completou o cenário, e contabiliza 3

pontos

1 ponto pela carta jogada e mais 2 pontos por completar o cenário.

BDD Warriors
Pontuação - Três pontos
É contabilizado 3 pontos a cada carta
coringa jogada de forma válida
BDD Warriors
Pontuação
OS PONTOS SÓ SÃO CONTABILIZADOS SE TODOS OS JOGADORES CONCORDAREM
QUE O CENÁRIO É LÓGICO E SEGUE AS REGRAS DO BDD.

Caso os jogadores não concordem com o cenário, o jogador que completou deve receber a opção
de melhorar o cenário com uma nova jogada.
BDD Warriors
Cartas especiais - Carta de ação
Quando jogada, o jogador deve seguir as instruções da carta e encerrar sua jogada atual.
BDD Warriors
Ex:
Cartas especiais - Coringa
Dado um ninja
Para ser jogada deve conter a palavra-chave do cenário; Quando o ninja chegar em casa
O jogador deve completar a descrição da carta;
Só pode ser jogada para completar um cenário;
BDD Warriors
Término do jogo:
O jogo pode ser encerrado de 2 formas:

Quando algum dos jogadores atingir o nível máximo de pontos pré estabelecidos.

Quanto o jogo atingir o limite do tempo pré estabelecido e um dos jogadores somar mais pontos
que os demais.
QUE COMECEM

OS JOGOS !