Slides da 1ª de uma série de 4 lives sobre testes automatizados em Ruby. Assista todas! Fábio Araujo remove mitos sobre BDD e destaca a sua importância na comunicação dentro e fora da equipe com objetivo de garantir os resultados para o negócio e a qualidade dos softwares necessários. Desafios, formatos e ferramentas são apresentados, formando uma grande base de conhecimento sobre o Desenvolvimento Direcionado por Comportamento (BDD). Um dos grandes, senão o maior, gerador de defeitos em software é a comunicação humana, cujas falhas naturais e frequentes pode levar ao fracasso os mais variados projetos em organizações de qualquer porte ou orientação. Este vídeo não requer que você tenha assistido nenhum outro conteúdo da série.

1. BDD da
especificação
à automação
Fábio Araújo

2. Chapter Lead – Q.A
• Mais de 20 anos na área de T.I,
sendo 12 anos na Área de Q.A;
• Digibase - Maplink - Google Maps,
Magneti Marelli, Valor Econômico,
Amil, Dotz, Linx, Edenred -Ticket
& Via Varejo;
• Acadêmico: Eletrotécnica, Sistemas de
Informação & Gestão de Qualidade.
Fábio Araújo
Instagram: @fabiokaia
Linkedin: https://www.linkedin.com/in/fabio10/

3. Agenda
Parte 1: BDD – Conceitos
• BDD no 2me Ágil
• Técnicas de escrita
Parte 2:
• Demo: Automação com Ruby
Fábio Araújo
BDD da especificação à Automação
04/06 as 20:30hs
Automação Front-end – Ruby
11/06 as 20:30hs
Automação API Rest – Ruby
18/06 as 20:30hs
Integração Contínua (CI)
25/06 as 20:30hs
Eshilane Cruz
Raphael Alencar
Ernesto Barbosa

4. BDD – Behaviour Driven Development
• Desenvolvimento orientado a comportamento criado por Dan North;
• É um conjunto de práticas ágeis integrando Histórias de usuário com
Automação dos testes funcionais;
• É uma evolução de técnicas do TDD (Test Driven Development);
Falha
Passa
Refatora

5. BDD – Por que?
• Melhora a comunicação entre DevTeam e Negócio;
• Equipe focada em seu objetivo;
• Código documentado;
• Garante a regressão das funcionalidades;
• DevTeam como dono da solução;
• Acelera a criação dos testes automatizados. “Vocês verão!!!”

6. BDD + Ágil
• Escrever menos
• Reaproveitamento
• Melhor entendimento
• Obje=vo
• Claro
• Documento vivo
Ágil
BDD

7. Comportamento do usuário
• Conversa com usuário:
“Se eu fizer isso e isso, eu espero esse resultado”
• E se eu pudesse criar um teste literalmente escrevendo algo assim?
Dado uma pré-condição
Quando eu executo uma ação
Então o resultado é esse

8. BDD – Como é ?
2- P.O junto com o
DevTeam elaboram o
requisito e definem a
estrutura dos cenários.
3- Os cenários guiam
o desenvolvimento...
... e serve como base para
os testes funcionais/
automa>zados.
4- Usuários usam os
cenários para
homologar.
1- P.O e Usuário(s)
tem uma conversa
sobre o que desejam
desenvolver.

9. “Os Três amigos”
Conversas do
usuário
Reunião com três principais papéis do time (Product Owner, Desenvolvedor, Analista de
Qualidade);
Histórias bem definidas e
Critérios de aceitação
Q.A
P.O Dev.
Que problema estamos
tentando resolver?
Como desenvolver esta
solução?
E quanto a isso, o que poderia
acontecer?
Agora temos o mesmo
objetivo

10. Ferramentas para BDD
BDD não é ferramentas, mas existem ferramentas que auxiliam a
implementação.
Ex.:
Obs.: Não existe uma ferramenta melhor ou pior: a escolha de qual framework e
linguagem uVlizar deve ser pensando nas habilidades técnicas da equipe.

11. BDD - Gherkin
O vocabulário comum em BDD é o Gherkin.
-Criada especialmente para descrições de comportamento;
-Remove detalhes da lógica de programação e foca no comportamento que uma
funcionalidade deve ter;
Um arquivo Gherkin é semelhante a um Caso de teste. Nele contém:
• Título da funcionalidade;
• Descrição da funcionalidade;
• Cenários com passo a passo;
• Resultado esperado.
Referencia: https://cucumber.io/

12. Caso de teste vs BDD
Referencia: https://cucumber.io/
BDD
Cenário: Cadastro de pessoal física
Dado que eu acesse a pagina de cadastro
Quando Inserir os campos obrigatórios
E clicar no botão Cadastrar
Então deve aparecer uma mensagem de boas vindas
E enviar um e-mail de confirmação de cadastro
Caso de teste
Cadastro de pessoal Rsica
Passo a passo:
-Acessar a pagina de cadastro
-Inserir os campos obrigatórios
-Clicar no botão Cadastrar
Resultado esperado:
-Deve aparecer uma mensagem de boas vindas
-Enviar um e-mail de confirmação de cadastro
Funcionalidade: Credenciamento no Linkedin

13. • Uma funcionalidade de autenticação que um P.O pode escrever em alto-
nível:
• Isso já pode ser uma documentação viva dentro do BDD, mas podemos
melhorar explicando esse recurso, dividindo em cenários por exemplo:
• Autenticação válida;
• Usuário inexistente;
• Usuário com senha inválida;
• Etc...
Como usuário do Linkedin
Quero me autenticar
Para que eu possa visualizar novos posts
Exemplos

14. Implementação
Funcionalidade: Autenticação no Linkedin
Como usuário do Linkedin
Quero me autenticar
Para que eu possa visualizar novos posts
Cenário: 1 - Auten+cação válida
Dado que eu acesse a página de autenVcação do Linkedin *
Quando eu digitar o usuário “João da Silva”
E a senha “abc@123”
Então deve ser exibido a mensagem de boas vindas: “Olá João”.

15. Cenário: 2 - Usuário inexistente
Dado que eu acesse a página de auten?cação do Linkedin *
Quando eu digitar o usuário “José Ninguém”
E a senha “abc@123”
Então deve ser exibido a mensagem “Usuário não cadastrado em nossa base”
Cenário: 3 - Usuário com senha inválida
Dado que eu acesse a página de autenticação do Linkedin *
Quando eu digitar o usuário “João da Silva”
E a senha “123456”
Então deve ser exibido a mensagem “Usuário ou senha inválidos”
Implementação

16. Otimizando: Contexto
Por vezes, você se verá repetindo as mesmas etapas (Dado) em todos os
cenários de uma Funcionalidade.
Isso é uma indicação de que essas etapas não são essenciais para
descrever os cenários, mas servem como pré-requisitos ou detalhes do
cenário.
Você pode usar um recurso, agrupando estas etapas num segundo
plano, em uma seção de “Contexto” (Background).
O “Contexto” é inserido antes de cada cenário como no exemplo a
seguir:

17. Otimizando: Contexto
18
Contexto:
Dado que eu acesse a página de autenVcação do Linkedin *
Cenário: 1 - Auten+cação válida
Quando eu digitar o usuário “João da Silva”
E a senha “abc@123”
Então deve ser exibido a mensagem de boas vindas “Olá João”.
Cenário: 2- Usuário inexistente
Quando eu digitar o usuário “José Ninguém”
E a senha “abc@123”
Então deve ser exibido a mensagem “Usuário não cadastrado em nossa base”

18. O"mizando: Parâmetros
19
Podemos também usar o auxílio de tabelas para inserir os parâmetros
de dados repetitivos.
Chamamos esse recurso de “Esquema do cenário” (Scenario Outline).
Este recurso permite até usarmos dados de um arquivo (txt, xls, csv,
json, etc) ou banco de dados, diminuindo ainda mais trabalhos
repetitivos, como uma grande massa de dados.

19. Otimizando: Parâmetros
20
Contexto:
Dado que eu acesse a página de autenticação do Linkedin*
Esquema do Cenário: Autenticação válida
Quando eu digitar o <usuario>
E a <senha>
Então deve exibir a <mensagem> de boas vindas na pagina principal
Exemplos:
| usuario | senha | mensagem |
| “joao@dominio.com” | “123@abc” | “Olá João” |
| “maria@dominio.com” | “123@abc” | “Olá Maria” |
| “jose@dominio.com “ | “123@abc” | “Olá José” |

20. Otimizando: Tabela de dados
21
Existe uma maneira mais simples de passar Lista para uma definição na
etapa , usando uma tabela de dados.
Este recurso permite que você passe uma lista de pré-requisitos no “Dado”
com parâmetros pré-definidos.
Esta lista é passada antes de executar uma ação no “Quando”, diferente do
“Esquema do Cenário’ que faz parte da ação.
Veja o exemplo a seguir:

21. Otimizando: Tabela de dados
22
Funcionalidade: Cadastro
Cenário: Cadastro pessoa física
Dado que eu acesse o formulário
E que eu tenha os seguintes dados de usuários:
| nome | cpf | e-mail |
| “Fábio Araujo” | “7328459900” | ”fabio@dominio.com”|
| “João da Silva” | “29088129200” | “joao@dominio.com” |
| “José de Souza” | “21048039001” | “jose@dominio.com” |
Quando eu fizer o cadastro completo
Então o usuário deve ser cadastrado na base

22. Palavras reservadas do Gherkin
23
#language: pt
Feature Funcionalidade
Scenario Cenário
Given Dado
When Quando
Then Então
And E
Or Ou
But Mas
Scenario Outline Esquema do Cenário
Background Contexto
Examples Exemplos
... ...

23. Bugs - Como descrever?
24
• Bugs são comportamentos incorretos de uma aplicação
• Este formato é excelente para que o =me de desenvolvimento
entenda o comportamento incorreto e os critérios de aceite
da correção.
Título da correção
Dado o cenário
Quando ocorre um determinado evento
Então ocorre um comportamento inesperado
Anexos
•Imagens, json, xml, prints, etc.

24. Exemplo de Bug com BDD
25
Título: Não aparece imagem do Iphone na
página de produto
Dado que eu busque o produto Iphone XR : SKU
000XXXYYY
Quando for direcionado para a página de produto
Então não é exibido a imagem do produto

25. Demo. 1 – Automação de testes com BDD
#language: pt
Funcionalidade: Calculadora
Como não sei fazer conta de cabeça
Quero usar a calculadora do sistema
Para obter os resultados corretos
Cenário: Soma de dois números
Dado que acesse a calculadora
Quando eu somar 2 + 3
Então o resultado da soma deve ser 5
26

26. Demo. 2 – Automação de testes com BDD
27
#language: pt
Funcionalidade: Calculadora
Esquema do Cenário: Soma de 2 números com tabela
Dado que eu acesse a calculadora
Quando eu somar o <valor1> com <valor2>
Então o resultado deve ser <total>
Exemplos:
| valor1 | valor2 | total |
| 5 | 7 | 12 |
| -8 | 10 | 2 |
| 800 | 150 | 950 |

27. Obrigado!
Fábio Araújo
https://www.linkedin.com/in/fabio10/
Apoio: