Você sabe o que é BDD (Behaviour Driven Development)? se não sabe, pelo menos já ouviu essa sigla em algum lugar.

Neste texto eu explico o que é BDD e também como escrever boas user stories (histórias de usuários) com cenários de teste, que serão muito úteis para automação dos testes.

O que é BDD 

O mais comum no contexto de desenvolvimento de software é ouvir falar pelo menos de TDD (Test Driven Development), que é a técnica que originou o BDD.

De forma simplificada, o BDD (behaviour driven development) ou também conhecido como especificação por exemplo, é uma técnica de desenvolvimento ágil que incentiva a colaboração entre os membros da equipe e tem como foco a descrição do comportamento do programa que será construído.

Essa forma de trabalho pode ser utilizada independente do tipo de software que será produzido: programa de desktop, app, mobile, web…

Ao definir o funcionamento do programa que será feito, existe a colaboração de especialistas de várias áreas: qa’s (testadores), product owners (gerente de produto), business analysts (analistas de negócios). Essa colaboração é conhecida como three amigos.

Observe que essa colaboração de especialistas de diversas áreas não é algo totalmente novo e específico do BDD, mas é algo pregado pelo próprio manifesto ágil e presente em outros métodos ágeis como SCRUM ou XP. 

Na hora de testar o software focaremos também em se testá-lo ponto de vista do seu comportamento. 

Isso quer dizer que ao se desenvolver os casos de teste, o foco é no comportamento do software, de forma mais ampla, ao contrário do que fazemos no “teste de software clássico”, no qual detalhamos bem tecnicamente os casos de teste.

Apesar do que muita gente pensa, o BDD não é uma técnica de teste que existe apenas para automatizar os testes, mas uma técnica de desenvolvimento que ajuda a construir melhores testes.

O ponto central do BDD está em descrever o comportamento do software (e consequentemente, os testes) antes de codificar o software de modo que os testes guiem o desenvolvimento do software.

Assim, se escrevermos os testes somente após o software estar pronto, isso não é aplicar o BDD corretamente porque os testes não estão guiando o desenvolvimento.

Com essa forma de realizar testes, também é possível criar testes que execitem o fluxo inteiro de determinada função (end to end testing) e não somente uma função específica.

Por que usar BDD?

Usar o BDD ajuda melhorar a qualidade do produto de uma forma geral pois incentiva a colaboração da equipe desde o início, promovendo o alinhamento do conhecimento desde o início.

É interessante descrever o funcionamento do software nesse formato porque várias ferramentas de teste são capazes de executar esses cenários de usuário. Isso ajudará a criar os casos de testes mais rapidamente.

Além disso, usar o BDD falicita a conversa e o entendimento entre as equipes, ajuda na legibilidade e desacopla a descrição das funções do software das questões técnicas das implementações dos testes.

Um exemplo de ferramenta muito famosa que possui esse poder é o cucumber, que fornece suporte para várias linguagens de programação (Java, Ruby …) e idiomas (Inglês, Português …).

Como escrever  boas histórias e bons cenários de BDD

Os cenários são escritos usando o padrão composto por palavras chave:

As-I want-so (Como-Eu quero-Para) 

given-when-then (dado-quando-então).

Cada uma dessas palavras chave é usada da seguinte forma:

Como 

Papel que desempenha alguma ação no produto em teste

Eu quero

Realizar alguma ação no produto sobre teste

Para

Algum resultado específico, ou que algo seja feito

Cenário 1

Dado

Pré condições  para o meu teste

Quando

Realizo alguma ação no meu produto em teste

Então

Alguma coisa deve acontecer (o que eu quero que aconteça e irei verificar no meu teste)

Cenário 2

Dado

… 

Quando

… 

Então

….

Além dessas palavras chave acima, podemos usar a partícula “E” para compor cenários mais complexos.

Exemplo de história de usuário com cenários

Como: cliente do banco “Porquinho da felicidade” eu tenho o app do banco instalado no meu celular

Eu quero: ser capaz de controlar a minha conta corrente a partir do app

Para: ter melhor controle sobre meu dinheiro

Cenário 1: realizar transferências da conta corrente 

Dado: que eu esteja logado na minha conta do banco;

E: possua um limite de conta maior que 0 ;

Quando: eu tentar realizar a transferência de um valor maior que 0;

E: menor que o limite de transferência pelo app;

E: menor que o limite da minha conta;

Então: o banco deverá autorizar e realizar a transferência do dinheiro; 

E: eu devo rececber um sms confirmando a transação bancária. 

Observe que esses cenários não entraram em detalhes técnicos como:

qual a tela do app eu devo clicar?

em qual botão o clique será realizado?

devo estar logado com a conta XPTO?

qual o tempo de sessão do app?

a cor do texto é vermelha, verde, amarela? 

Essa “ausência de detalhes” é de propósito. Ou seja, não queremos detalhar muito os nossos cenários, a ponto de eles ficarem exatamente iguais os casos de teste clássicos cheios de informação e impossíveis de se manterem atualizados. 

Cuidado com Ambiguidades

Toda língua que não seja fomal é cheia de ambiguidades. É importantíssimo prestar atenção e tomar cuidado com ambiguidades ao escrever as histórias de usuário e os exemplos.

É bem fácil escrever algo ambíguo em Português, que será claro para quem está escrevendo mas não tão claro para outros membros da equipe. 

Uma boa forma de procurar por ambiguidades, é isolar cada palavra em uma frase em busca dos sentidos que eles podem ter. Escrever as histórias nas reuniões de refinamento do backlog também é uma boa prática que auxilia evitar descrições incompletas ou confusas.

Concluindo

O mais importante na hora de escrever essas histórias no formato BDD é focar em comportamentos. A granularidade dos testes irá depender da necessidade do produto em teste, assim como explico nesse texto aqui sobre casos de teste.

Referências

• https://www.researchgate.net/profile/Bazil_Parv/publication/220369134_Behaviour-Driven_Development_of_Foundational_UML_Components/links/004635321ac75a14d8000000.pdf
• https://books.google.co.uk/books?hl=pt-BR&lr=&id=fA9QDwAAQBAJ&oi=fnd&pg=PT14&dq=behaviour+driven+development&ots=_mWb-ZV8pd&sig=HpCdr5zzDtTr9IWLE2wWeUZaFJ0#v=onepage&q=behaviour%20driven%20development&f=false
• https://docs.cucumber.io/bdd/overview/
• https://docs.cucumber.io/bdd/better-gherkin/
• http://www.seilevel.com/requirements/the-art-and-science-of-disambiguation