BDD: {“team”:{“interaction”:{“success”: true}}}
“O trabalho com excelência investido em uma coisa errada ou de forma errada, é vão!”
O BDD (Behavior-Driven Development ou Desenvolvimento Orientado a Comportamento) é uma metodologia para desenvolvimento ágil de sistemas que visa integrar regras de negócio com linguagem técnica, por meio de uma comunicação clara e alinhada entre pessoas de negócio, equipe técnica e até mesmo o cliente.
O objetivo principal desta metodologia é incentivar a comunicação entre os envolvidos no projeto(compreensão compartilhada) para que o contexto de cada funcionalidade seja entendido corretamente por todos os membros da equipe, antes do início do desenvolvimento. Isso ajuda a identificar os principais cenários para cada história e também erradica as ambiguidades dos requisitos.
Originalmente concebido em 2003, por Dan North, é uma resposta ao TDD (Test Driven Development ou Desenvolvimento Guiado por Testes) de forma complementar, não substitutiva. O BDD complementa o TDD pelas seguintes práticas:
- Aplicar o princípio “5 Por quês” implicitamente a cada história de usuário proposta, para que seu objetivo esteja claramente relacionado aos resultados de negócios;
- Pensar “de fora para dentro”, em outras palavras, implementar apenas os comportamentos que contribuem mais diretamente para esses resultados de negócios, de modo a minimizar o desperdício;
- Descrever comportamentos em uma única notação que é diretamente acessível a especialistas, testadores e desenvolvedores de modo a melhorar a comunicação;
- Aplicar essas técnicas até os níveis mais baixos de abstração do software, prestando atenção especial à distribuição do comportamento, para que a evolução permaneça barata.
Mas… por onde eu começo?
Nosso primeiro passo deve ser entender qual o problema que queremos resolver, ou a meta que queremos atingir, a partir daí as especificações são produzidas e, com a colaboração do time, chegamos ao design da solução.
No BDD, as especificações são feitas com Histórias de Usuário, que simulam casos verdadeiros de uso, ou seja, Especificações por Exemplo. As Especificações por Exemplo(SbE) tem como finalidade deixar claro quais são as hipóteses de comportamento que esperamos ter, buscando uma visão humanizada e tangível do uso da solução.
User Story
Ao contrário do que muitos acreditam, o desenvolvimento de software não começa quando os desenvolvedores iniciam a estruturação do código. O desenvolvimento de software começa na fase de análise, e principalmente na especificação dos requisitos.
Não basta que sua equipe possua desenvolvedores altamente capacitados e responsáveis se a especificação que eles recebem é incompleta, superficial, ou burocrática demais. Se a especificação do software é ruim, o resultado do trabalho provavelmente será um software igualmente ruim. (Histórias de Usuário 3ª Edição, 2014, RAFAEL HELM E DANIEL WILDT).
Para este fim, usa-se a prática de especificação por User Stories. User Story (ou História de Usuário) é uma descrição concisa de uma necessidade sob o ponto de vista desse usuário, seguindo um determinado padrão, que busca descrever essa necessidade de uma forma simples e leve. Além do critério INVEST (Independente, Negociável, Valioso, Estimável, Pequeno, Testável), uma história do usuário deve ser escrita de uma maneira conclusiva, ou seja, deve terminar com a conquista de uma meta significativa.
Um dos princípios por trás das User Stories é a de que o produto poderia ser integralmente representado por meio das necessidades de seus usuários.
Funcionalidades(Features)
As funcionalidades devem ser especificadas com o padrão Quem-Oque-PorQue(a ordem pode alterar), que é essencialmente a história do usuário, seguido por pelo menos um cenário(exemplo), conforme exemplo:
Funcionalidade: Alguma descrição breve e clara do que é desejado
Como algum protagonista (Quem?)
Quero alguma coisa (O que?)
Para alguma finalidade (Por que?)Cenário: …?
Cenários
Os cenários devem ser estruturados em torno do padrão Contexto-Evento-Resultado do Gherkin e são uma maneira de explicar como um determinado recurso deve se comportar em situações diferentes ou com diferentes parâmetros de entrada.
Gherkin é uma linguagem de domínio específico criada especificamente para a descrição de comportamentos, que usa um conjunto de palavras-chave especiais para fornecer estrutura e significado às especificações e serve tanto como especificação quanto como entrada em testes automatizados, conhecida como “Especificações Executáveis”.
Exemplo de Cenário:
Cenário: Alguma situação de negócios determinável
Dado que alguma pré-condição (Contexto)
E* alguma outra pré-condição
Quando alguma ação do ator (Evento)
E alguma outra ação
E ainda outra ação
Então algum resultado testável é alcançado (Resultado)
E algo mais que podemos checar acontece também
* o E não é obrigatório mas se for necessário, use sem medo.
Especificando cenários de bugs
Bugs também viram User Stories? Nope!
Escrever histórias de usuários para relatar bugs não é uma boa prática, elas servem especificamente para detalhamento de novos requisitos, ou para evolução de requisitos. MAS, relatar os bugs no formato de cenários é interessante, e é uma prática que tem se tornado muito comum ultimamente.
A descrição funciona como os passos para reprodução do bug, além disso, podem ser inseridas algumas outras informações, como: pré-requisitos, comportamento esperado, situações específicas, versão, etc.
Exemplo:
Cenário: Crash no cadastro quando inseridos caracteres especiais no campo nome.
Dado que quero realizar meu cadastro no app X
E possuo um smartphone X
E estou com a versão X instalada
Quando clico no botão de cadastrar
E insiro meu nome com um asterisco no campo
E clico em próximo
Então o app fecha
E me retorna a mensagem de erro: “blábláblá”
O importante é que a descrição fique clara e compreensível para todos.
Conte-me mais sobre Especificações Executáveis
Para executar as especificações escritas em linguagem Gherkin, existem diversos frameworks para testes automatizados com BDD, como: jBehave, Cucumber, Specflow, entre outros. Para que estes frameworks possam reconhecer e executar as especificações, as mesmas devem ser salvas em arquivos de texto com extensão “.feature”.
As histórias e cenários contidas nos arquivos de feature devem focar no “o quê” em vez de no “como”. Os cenários devem ser concisos e diretos, para que o leitor possa compreender rapidamente a intenção do teste sem ter que ler muitos passos irrelevantes e preferencialmente devem conter exemplos de dados de entrada.
Abstraindo as demais configurações para não entrarmos demais no lado técnico, basicamente o framework executa da seguinte forma: lê as especificações no arquivo .feature, verifica os steps(passos a serem executados) conforme a estrutura, reconhece a existência de cada step a ser executado dada as suas anotações(@Given, @When, @Then e @And) e nome, e então executa os testes automatizados conforme foi implementado :).
Isso significa que aquela mesma especificação feita na fase de análise com o cliente, passa pelos analistas, desenvolvedores e testadores. Awesome!
Por que eu devo adotar o BDD?
De fato o BDD é uma ótima maneira de evitar uma situação comum que encontramos no processo de desenvolvimento de software entre as equipes. Em geral, o problema comum que encontramos é a falta de comunicação entre os lados, o que implica que os desenvolvedores não entendem o que é necessário para o próprio negócio e os profissionais de negócios entendem mal o que os desenvolvedores são realmente capazes de fazer.
Neste modelo, a forma de documentação do projeto deve ser também a mesma que de interação: ágil! Usamos o conceito de Documentação Viva. A documentação é viva porque funciona como um organismo, é dinâmica e acompanha o processo de desenvolvimento desde o levantamento de requisitos e de cenários funcionais até a conclusão das funcionalidades, gerando documentos e artefatos conhecidos por todos os envolvidos no projeto. Quem dá vida a essa documentação é o time inteiro, é algo que evolui junto com o desenvolvimento do software, com o envolvimento de todos os interessados.
Além disso, existem diversos benefícios em aderir o BBD nos projetos, alguns deles são: alto nível de interação e colaboração do time, alta visibilidade do negócio, design do produto fiel ao valor comercial, foco em atender as necessidades dos usuários e confiança no que está sendo desenvolvido. Tudo isso impacta diretamente no que, para mim, é o mais importante: qualidade do produto.
Peace!
___________________________________________________________________
