BDD simples assim!

Direto ao ponto, o que é BDD?

BDD é uma mudança de pensamento é ser protagonista!

• BDD é Behavior Driven Development ou em português, desenvolvimento guiado por comportamento.

Podemos notar que na frase “Behavior Driven Development” não se encontra a palavra “Teste”, não existe “Behavior Driven test”, portanto escrever cenários em BDD deve ser uma especificação para guiar o processo de desenvolvimento de um software.

A sintaxe Gherkin é utilizada para especificar cenários utilizando o:

O BDD não tem como motivo ser utilizado para Teste de software, e sim escrever os cenários em BDD para enriquecer o processo como um todo, para trazer uma documentação rica e colaborativa com o time de desenvolvimento.

BDD vem antes da atividade de codificação do software, antes de codificar a funcionalidade, escreve-se os cenários podendo utilizar essa técnica para enriquecer as histórias dos usuários, tornando assim o objetivo daquela funcionalidade mais clara, trazendo um alinhamento de entendimento e expectativas junto a toda equipe.

Então usar o BDD é, vamos desenvolver essa feature orientada a esse comportamento e consequentemente testar orientado a esse comportamento. Dessa forma, temos um processo de desenvolvimento orientado a comportamento utilizado da maneira correta.

Exemplo disso tudo na prática:

Personagens: PO 🧕, Dev 👨🏻‍💻, QA 🕵️‍♀️

Utilizando a técnica do BDD um QA enriquecerá uma “user story” dentro de um time que utiliza técnicas do desenvolvimento ágil. Dessa forma o QA será um agregador/colaborador dentro do time, garantindo a qualidade em todo o processo e não garantir a qualidade somente na etapa do teste.

Vamos imaginar que o PO 🧕 compartilhou alguns artefatos para o QA 🕵️‍♀️, esses artefatos são:

Uma história do usuário para fazer o desenvolvimento da funcionalidade em questão.

• Wireframe da tela a ser desenvolvida.

🕵️‍♀️. Então a principal função aqui como testador é, esclarecer de uma forma efetiva para que os stackholders entenda qual é o nosso objetivo, quais são as nossas expectativas e efetuar o alinhamento dessas expectativas.

Para identificar que uma história de usuário foi bem feita ela deve conter três linhas:

1ª Linha: identifica o ator, é quem vai utilizar a funcionalidade

2ª Linha: indica aquilo que deve ser desenvolvido

3ª Linha: indica o valor agregado para o negócio (o motivo do negócio)

CONVERSA COM O PO 🧕💬

— 🕵️‍ , olá PO veja se é isso mesmo que você deseja, perguntou o QA;

O que acontece PO? quando eu clicar no botão cadastrar, para onde eu serei redirecionado, pois, pelo wireframe não consigo perceber isso? (“…eu preciso entender o que vai acontecer para que eu possa lhe ajudar a especificar, para que o nosso time desenvolva com muita qualidade e evitar possíveis bug’s…”)

— 🧕, “quando o utilizador submeter o cadastro ele deve ser redirecionado para a página home da área logada, disse o PO”.

— 🕵️‍♀️ “ahh entendi…”

— 🕵️‍♀️ “é isso que você precisa PO?”

— 🧕, “exatamente, é isso que eu quero, estou satisfeito com esse resultado.”

Até aqui tudo bem, certo? Não tem muito mistério, o BDD é bem intuitivo, o que faz o BDD mais eficaz é atuação do profissional que o está utilizando ;)

Vamos lá…

— 🕵️‍♀️ “olha que legal PO, vou lhe passar outros cenários para tentarmos cobrir o máximo possível e garantirmos a qualidade dessa feature…”

— 🧕, “muito bem QA, vamos nessa!”

— 🕵️‍♀️ “então, PO, o que acontece se o usuário não informar o e-mail?”

— 🧕, “humm… eu não tinha pensado nisso…”

— 🕵️‍♀️ “mas, tudo bem, podemos mostrar uma mensagem informando que o e-mail é um campo obrigatório”

— 🕵️‍♀️ 🧕 “Vamos especificar esse cenário!”

— 🕵️‍♀️ “ e se eu não digitar a senha PO?

— 🕵️‍♀️ 🧕 “Vamos especificar esse cenário também QA!”

— 🕵️‍♀️ “PO faz sentido isso para você?”

— 🧕, “Sim, QA é exatamente isso que eu quero.”

— 🕵️‍♀️ “ótimo estamos indo bem, e se… no campo confirmar a senha o usuário digitar a senha errada?, o que acontecerá PO?

— 🧕, “nessa ocasião o sistema deverá retornar uma mensagem para informar que a senha está divergente.”

— 🧕 🕵️‍♀️, “Vamos especificar esse cenário também…”

— 🧕, “ Uau..!!! agora estou confiante, o sistema está muito bom ✓

— 🕵️‍♀️ “mas…”

— 🧕, “ … o que foi QA?”

— 🕵️‍♀️ “e se o usuário não preencher nenhum dos campos…”

— 🤦‍♀️🧕, “…nossa, não tinha percebido esse ponto…”

— 🕵️‍♀️ “Podemos fazer o seguinte cenário…”

— 🕵️‍♀️ agora sim, com esses cinco cenários acredito que a nossa feature está pronta para ser implementada.

🧕 🤝 🕵️‍♀️

Podemos visualizar que a técnica de desenvolvimento guiado por comportamento é muito eficiente, e ajuda a evitar possíveis bugs que passariam desapercebidos em outras metodologias convencionais, podemos ir além e considerar isso como um contrato entre o PO, Dev e com o time de qualidade, ou seja todos trabalhando com a mesma documentação orientado ao mesmo resultado.

Essa técnica envolve todos na cultura de uma qualidade mais abrangente, e não somente focada na hora dos testes.

Olha só que interessante, antes mesmos de começarmos a testar, ou até mesmo pensar em automatizar os testes, já garantimos e cobrimos uma grande parte da qualidade do nosso software.

Essa especificação de cenário voltada ao négocio, é simplesmente incrível e facinante!

Nos encontramos em breve, espero que tenha sido útil e agradável 🥰