O documento apresenta o Behavior Driven Development (BDD) e o framework Cucumber. Discute como o BDD e o Cucumber podem ser usados para melhorar os processos de teste e qualidade de software na Locaweb, movendo-se de uma abordagem de "Quality Control" para "Quality Assurance". O caso apresentado é um Proof of Concept de BDD e Cucumber para testes de infraestrutura como serviço (IaaS).

1. BDD com
Marcelo Toledo - QA - IaaS

2. Agenda
- O que é BDD e Cucumber?
- Motivação
- Case
- Considerações

3. O que é BDD?
Behavior Driven Development é uma técnica
que evoluiu a partir do TDD
É uma descrição do comportamento do
sistema e a partir disso, se desenvolve o
sistema
Colaboração entre Dev + QA + P.O. + UX

4. O que é Cucumber
É um framework, que surgiu da evolução de:
Jbehave -> Rbehave -> RSpec -> Cucumber

5. Características
Especificação do comportamento escrita em linguagem natural.
A especificação se torna teste e critério de aceitação, descrevendo
exemplos de comportamento do software antes da implementação
(feedback cedo).
Como qualquer teste automatizado, esses testes são usados na
regressão durante a evolução do software.
É uma especificação baseada no valor do negócio através de
exemplos de uso e de fácil compreensão.

6. QA x QC ?
Motivação

7. Motivação
- QC - Utilizado no processo de desenvolvimento
de software tradicional (RUP, Waterfall, etc)
- QA - Processo Ágil
- Precisamos alterar o processo de teste na
Locaweb, deixar de ser QC e realmente
começar a ser QA.

8. Motivação
O que estamos deixando para trás:
nossa “pirâmide” atual:

9. Motivação
Para onde estamos
caminhando:

10. CASE
- POC em IaaS
Há uma série de "combos" para se usar o BDD com a
linguagem Ruby:
- RSpec + Selenium Webdriver (PhantonJS??)
-> Cucumber + RSpec + Capybara + PhantonJS (ou Selenium)

11. CASE
Lições aprendidas:
- Escrever features declarativas
- Inserir narrativa nas features
- Evitar steps conjuntivos (mais de uma ação no
mesmo step)
- Reusar step definitions (utilizar variáveis nos steps)
- Não abusar do uso de backgrounds

12. CASE
Iniciamos com apenas uma feature: BACKUP
Temos por enquanto:
19 scenarios
147 steps
3m32.067s

13. CASE
Exemplo no Jenkins e estrutura do projeto

14. Obstáculos
- Identificação de um padrão inicial
- Indefinição quanto ao local do projeto
- Aprendizado do time
- Quebra de paradigma - resistência
(aprendizado, já faço teste, tempo de feedback)

15. Obstáculos
- Demora na implementação e entrega
(como qualquer teste realizado, ganha-se na frente)
- Elaboração de cenários errada pode levar a adoção ao
fracasso (nem todos os testes devem ser automatizados)
- Nem todo teste é automatizável (?????)

16. Vantagens
- Cucumber facilita outside-in, mas não força você a usá-
la desta forma
- Fornece testes legíveis e atrativos para todas as partes
do time inclusive as não técnicas, o que possibilita a
inclusão de todos neste processo (QA, PO, UX)
- Aumento de comunicação, amenizando ambiguidade
- Regressão = garantia

17. Vantagens
Ajuda o time a:
- Compreender melhor os requisitos através
de exemplos.
- Ter uma documentação viva (executável) e
de fácil leitura.
- Mais uma forma de testes de regressão.

18. Considerações finais
- Testes não garantem ausência de defeitos.
- TDD contribui para qualidade interna e reduz custo e
tempo de manutenção do produto, portanto, pode ser
aplicado também.
- BDD contribui para qualidade externa e reduz custo e
tempo de revalidação das funcionalidades do produto.
- Eliminar gargalo em QA.
- Caminhar para Continuous Delivery/Deployment.