O que você precisa saber sobre BDD
Neste artigo, trataremos sobre BDD (Behavior-Driven Development / Desenvolvimento orientado ao comportamento) metodologia ágil que permite um melhor entendimento dos requisitos levantados e facilita a formalização dos requisitos por todos os envolvidos no projeto.
Trarei algumas boas práticas de elicitação baseada em comportamento e alguns motivos para adotar em seu processo de desenvolvimento de software.
Como tudo começou
Em 2003 Kent Beck idealizou o TDD (Test-Driven Development / Desenvolvimento orientado ao teste), precursor do BDD, dentro da metodologia Extreme Programming. Sua premissa propõe que os testes devem ser escritos antes do código do software, para gerar a falha e assim guiar o Desenvolvimento para chegar no resultado esperado.
Os desenvolvedores irão se basear nos testes falhos, para implementar a aplicação de maneira a passarem, e refatorar seu código de maneira cíclica, até que fique mais limpo (princípio do Clean Code). O que foi chamado de Red-Green-Refactor. Contudo, a grande vantagem desta prática não é gerar testes, e sim pensar no design e nas regras de negócios antes de escrever qualquer linha de código.
Moldar uma aplicação baseado em testes é uma alternativa viável, porém devemos levar em conta que pode ser dificultoso sua utilização em um primeiro contato. Não é testar em si a maior barreira, mas sim o entendimento do que se deve esperar de determinado teste e o que realmente é necessário testar.
A inviabilidade é o isolamento do desenvolvedor para pensar testes e aplicá-los para que gerem erro e tente refiná-los, sem a clarificação do objetivo a ser alcançado, principalmente se a equipe de desenvolvimento, clientes e áreas de negócios não falarem a mesma “língua”. Dan North em 2004 então respondeu essa necessidade com a criação do BDD, que possui três princípios básicos:
· Tudo é comportamento: A área de negócios e a de Tecnologia devem se referir para o sistema da mesma forma;
· Onde está o valor do negócio: Todo sistema deve ter comportamentos que sejam um verificador do valor para o negócio;
· Faça o suficiente: Analisar, projetar e planejar tudo de cima para baixo, evitando o detalhamento prematuro.
Foco com BDD
BDD, é uma metodologia de desenvolvimento ágil que visa focar o comportamento esperado de um sistema mediante seu requisito de negócio explicito. O foco é a confirmação do entendimento da regra de negócio por todos os envolvidos no desenvolvimento.
Utilizando práticas como “User story”, “critérios de aceitação” e “Linguagem Ubíqua”, faz sua curva de aprendizagem menor, e possibilita equipes com novos integrantes entregarem resultados muito mais rápidos e com maior qualidade.
Em conjunto, Stakeholders, equipe de negócios e equipe de desenvolvimento, validam desde a elaboração das estórias de usuários até a entrega. Através de sua linguagem universal (ou Linguagem Ubíqua) a comunicação é limpa dos “ruídos” causados pelo uso dos jargões de áreas distintas, focando em envolver a todos no refinamento dos requisitos e em testa-los ainda na concepção da ideia.
Processo de desenvolvimento baseado no BDD
A proposta é que Stakeholders e áreas de negócio façam o levantamento dos requisitos de funcionalidade de uma nova aplicação através “user story” e criem seus respectivos “cenários” no formato do Gherkin para imaginarem os resultados esperados, permitindo a compreensão do comportamento que a solução deve ter para suprir as necessidades propostas.
Após essa primeira etapa, serão realizadas reuniões (Planning do scrum ou Reabastecimento do Kanban) junto a equipe técnica, onde as User Stories e cenários serão validados e refinados (adicionando ou removendo critérios de aceitação) por todos, e se verificará a viabilidade de seu desenvolvimento.
Em seguida passará pela técnica do ATDD (Acceptance Test-Driven Development / Desenvolvimento Orientado a Testes de Aceitação) onde a equipe de desenvolvimento decidirá as abordagens que serão utilizadas para a validação dos cenários (E2E, Integração, Unitário e etc).
Para o desenvolvimento recomenda-se a utilização do TDD, tendo os cenários que descrevem os resultados esperados, torna-se mais simples a prática do “Red-Green-Refactor”.
Durante a codificação da funcionalidade, os QAs já podem se concentram na codificação dos testes automatizados E2E, aplicando o mesmo processo de red-green-refector, associados aos cenários Gherkin utilizando frameworks como Cucumber, RSpec entre outros. Nesse caso com o Cucumber, ao rodar os testes apenas com os cenários, gera erro, porém apresenta um a sugestão das “steps” de teste:
Após a entrega, os clientes podem seguir os cenários aprovados para homologação da aplicação, alinhando as expectativas e o que se espera da equipe de desenvolvimento.
Por ser uma prática ágil, é previsto que hajam mudanças no meio do projeto e durant qualquer etapa poderá ser formalizados cenários junto ao cliente, equipe de negócios e equipe de desenvolvimento.
Sobre Automação de Testes
A linguagem ubíqua Gherkin é utilizada em ferramentas de automação como para realizar testes automatizados e principalmente por ser semelhante a um caso de teste, mas conforme observado pelos criadores da ferramenta Cucumber:
“Um mal-entendido comum entre o TDD e o BDD é que eles são técnicas de teste. Pelo contrário, como o nome sugere, TDD e BDD são sobre desenvolvimento de software. É a abordagem que o força a pensar sobre o resultado desejado antes de codificar. Os testes automatizados são um subproduto do TDD e do BDD.”
Escrevendo requisitos com Gherkin
A escrita dos requisitos é utilizada em BDD para descrição de comportamentos de uma nova funcionalidade a ser desenvolvida voltada a alcançar um resultado para “negócios” removendo jargões de cada área responsável pelo desenvolvimento do projeto. Deve possuir as seguintes premissas:
1. Título da funcionalidade.
2. Descrição da funcionalidade (Estória de Usuários).
3. Cenários, compostos por uma sequência de etapas, que descrevem uma interação entre um usuário e o sistema, e possuem um critério de aceitação. Estes passos utilizando o princípio de DSL (Domain-Specific Language / Linguagens de Domínio Específico) com o objetivo de solucionar problemas em um domínio específico de aplicações.
Conforme exemplo:
1. Título da funcionalidade:
Deve ser uma breve descrição do que pretende ser desenvolvido, estando ao lado da palavra-chave: “Funcionalidade”, dando a intenção de que a partir deste, será descrito a ferramenta que alcançará um objetivo de negócio para o stakeholder.
Exemplo:
· “Funcionalidade: Cadastro de usuário”
Ou
· “Funcionalidade: Listagem de usuário”
2. Descrição da funcionalidade (User Story / Estória de Usuário)
Estória de usuário é uma ferramenta ágil para desenvolvimento de software que permite a contextualização para as pessoas que leem a funcionalidade, permitindo entender e empatizar com o Ator que será atendido pela nova funcionalidade.
Uma boa prática para torna visível o ganho de negócio e a necessidade desta funcionalidade é a aplicação do I.N.V.E.S.T. sigla para: Independent, Negotiable, Valuable, Estimable, Small, Testable, ou em português: Independente, Negociável, Valiosa, Estimável, Pequena e Testável, que traz recomendações para elaboração de uma estória de usuário, sendo:
· Independente: Estória de usuário deve ser independente de outras histórias.
· Negociável: Estória de usuário é desejo do stakeholder, logo, pode considerar sendo apenas um ponto de partida. Portanto, deve ser totalmente negociável, permitindo eliminá-la ou reescrevê-la.
· Valiosa: Deve representar valor de negócio, sempre. Sem valor de negócio não faz sentindo existir.
· Estimável: O time deve ser capaz de estimá-la.
· Pequena: Deve ser pequena e assim reduzindo as incertezas e dificuldades de estimativas.
· Testável: Devem ser testáveis, ou seja, deve ser possível validar se atingem os critérios de aceitação. Neste ponto utilizamos os “Cenários” que serão tratados em breve.
“Uma boa user story não deve depender de outra, deve ser possível negocia-la de forma que você possa alterar sua prioridade e ordem de execução com o cliente, deve agregar valor, deve ser possível estima-la, deve ser pequena (até para poder ser estimada), e deve ser testável.”
- RAFAEL HELM e DANIEL WILDT, Wildtech — start wild, keep wild
Para a escrita da Estória de usuário segue-se a premissa de três palavras chaves que dão a introdução e permitem um fácil entendimento do contexto:
· A fim de alcançar algum ganho ou valor.
· Como um “Alguém” (ator, papel) que tenha uma necessidade de negócio.
· Eu quero a funcionalidade expressada para alcançar este valor.
Embora essa sequência e as palavras chaves não necessariamente precisam ser mantidas, deve-se sempre levar em conta que precisa ser um texto breve e coerente:
Neste caso o usuário é o cliente de um serviço de streaming, a funcionalidade proposta, é que sempre apareça na tela inicial do serviço os lançamentos de filmes e o resultado alcançável é poder ver os novos filmes assim que lançados na plataforma.
3. Cenários
Os Cenários do BDD descrevem as interações que serão validadas. Eles devem conter passos lógicos e simples de como obter um resultado específico de negócio a partir de uma sequência de ações. Devem existir quantidades de cenários suficientes para validar o comportamento de uma nova funcionalidade através das interações descritas.
Serão sempre escritos na seguinte estrutura:
· Título: Alocado ao lado da palavra chave “Cenário:” provendo a informação da validação esperada para este cenário.
· Passos do cenário: Palavras chaves são utilizadas para definir “Passos” que compõem determinados cenários:
o Dado (Given) O propósito do “Dado” é colocar o sistema em um estado conhecido antes que o usuário comece a interagir com o sistema. “Dado” será utilizado então como uma pré-condição de um cenário.
o Quando (When) O Propósito do “Quando” é descrever uma ação chave que o usuário executa, resumidamente seria a ação de interação do usuário com o sistema, representando o “gatilho” para o critério de aceitação.
o Então (Then) O “Então” mostra as saídas, os resultados das ações executadas, seria basicamente os critérios de aceitações esperados, segundo as “pré-condições” e “ações” dos passos anteriores.
o E (And) será sempre utilizado para que não tenhamos que repetir as palavras-chaves acima, tornando nossa escrita mais limpa.
o Mas (But) O “Mas” seria a forma negativa do “Então”, basicamente, quando o resultado esperado for que o usuário NÃO DEVE receber / ter algo, ou como um contraponto ao “então” é recomendado utilizar o “Mas” tornando o cenário mais legível.
Permitindo então chegar ao resultado conforme exemplificado:
Boas práticas
Existem outra palavras-chaves e práticas que facilitam a utilização do BDD e aumentam a produtividade das equipes na escrita de requisitos.
Ordem das palavras chave
Devemos sempre manter nesse formato das palavras-chaves, “Dado”, “Quando” e “Então”, o ideal é nunca alterar a ordem. Possivelmente encontraremos cenários escritos em alguma ordem alternativa, mas é uma pratica ruim, considere reescrever esses cenários mantendo sempre a mesma alocação mencionada acima.
Cenários de BDD não são casos de teste
O foco do BDD é descrever como a interação com o sistema irá gerar um ganho de negócio, por isso não se deve escrever como um caso de teste, usando termos como “Campo”, “Botão”, “Janela”. Devemos escrever de forma “agnóstica” a componentes sempre trazendo ênfase ao “negócio”.
Caso precise descrever componentes, utilize Mockup e lista de componentes para facilitar a visualização do que é necessário para a montagem da tela. Separe sempre comportamento de tela de comportamento de negócio. De um ponto de vista prático, se refartarmos a tela e trocarmos os componentes, teremos que novamente reescrever os cenários, perdendo novamente o foco em ganho de negócios.
Esquema do cenário
Para evitar a repetição de cenário que possuam os mesmos passos, porém com entradas e saídas diferentes, recomenda-se a utilização do Esquema do cenário:
O exemplo acima, 3 cenários foram unificados em um único “Esquema do Cenário”. Embora tenha surgido como uma solução de frameworks de Gherkin para automação, essa prática facilita a não repetição exaustiva de cenários, tornando o uso do BDD mais fácil.
Vale ressaltar que essa prática pode facilitar a escrita, mas depende do nível de maturidade com BDD para aplicação, podendo ser no início confuso a validação para novos praticantes.
Contexto
Com a mesma ideia de agilizar a escrita, a utilização do “Contexto” evita repetir passos idênticos para os cenários. Do ponto de vista de framework tudo o que for indicado nessa etapa será “pré-carregado” para a execução de todos os cenários dessa funcionalidade. No caso da escrita, é só imaginar que todos os cenários possuem a mesma condição e não precisará ser repetido ao ser informado no “Contexto”. Devendo ser escrito sempre antes dos cenários que devem receber esses passos
#Hashtag — Anotações
Sempre utilizados para enriquecer a escrita, utilizamos “#” para adicionar uma anotação ou observação pertinente a funcionalidade ou cenário de validação. Outra prática herdada dos frameworks, mas torna legível alguns pontos que ajudam da compreensão do resultado esperado.
Imperativo versus declarativo
Existem essas duas formas de escrever cenários Gherkin. A imperativa costuma descrever todas as etapas que serão necessárias para chegar ao resultado esperado, o que facilita à equipe de desenvolvimento ter maior visibilidade de toda a interação para chegar ao resultado esperado:
Já a forma declarativa tende a ser escrita mais foca em dar o resultado esperado de forma menos “pesada” sem dar ênfase as etapas em si, mas não desconsiderando o processo:
As duas formas são válidas e sua utilização fica a critério da equipe qual é melhor para ser adotado em determinada ocasião. Mas vale ressaltar que a utilização do Imperativo é mais onerosa, e se houver refatoramento de uma tela e adicionarmos ou removermos etapas, será necessário reescrever o cenário, problema que o Declarativo não sofre.
Ainda sobre a forma Imperativa, existe uma prática ruim que é usar componentes de tela na escrita dos cenários, igual a casos de teste. Não faça isso!
Alguns motivos para adoção do BDD
Posso dar alguns bons motivos, a partir de experiencias obtidas na pratica para adotar o uso do BDD no seu processo de desenvolvimento.
Produtividade
Permitirá o aumento de produtividade, pois a curva de aprendizagem para realizar entregas com qualidades será menor. A escrita dos requisitos será de fácil entendimento e existirão mais testes unitário e de integração que deixam o código mais seguro e simples de se entender. Além de possibilitar os testes Ponta-a-Ponta a serem escritos em paralelo ao desenvolvimento.
Os novos integrantes de uma equipe podem entender mais rápido a regra de negócio baseado em comportamento e focar no resultado esperado para sua atividade. Sendo assim, a curva de aprendizagem se torna menor.
Outro ponto, é diminuir os retrabalhos pois os possíveis defeitos poderão ser previstos ainda na concepção das funcionalidades, evitando surpresas durante o desenvolvimento.
Documentação
A elaboração de documentação de software, que antes era uma dificuldade, se torna mais próxima do comportamento do sistema e mais fácil de se manter, pois estará em evolução constante a cada nova funcionalidade, e presente nos testes automatizados.
Existira uma diminuição na criação de documentação, o BDD permite centralizar vários artefatos do desenvolvimento de software, permitindo novamente focar na entrega do produto e não irá onerar a equipe em atividades redundantes ou desnecessárias.
Colaboração e responsabilidade com o projeto
A equipe como um todo passa a ser responsável pela escrita e validação dos requisitos desde o planejamento, permitindo atuar na prevenção de problemas ao invés de correções. O que promove a colaboração de todos os indivíduos e cria um aspecto multidisciplinar e auto gerenciável para a equipe, que prezará pelo resultado e possuirão a capacidade de estimar com maior precisão.
Conclusão
Espero ter dado uma introdução do assunto e possibilitado uma visão facilitada da metodologia. Seja em equipes ágeis ou não, BDD possui boas práticas que ajudarão no processo de desenvolvimento.
