Neste artigo falarei sobre BDD (Behavior-Driven Development, ou Desenvolvimento orientado ao comportamento), metodologia que permite uma melhor comunicação dos requisitos de negócio e como podemos utilizá-la em projetos ágeis para resultados mais rápidos e com maior qualidade.
Nesse momento tratarei apenas de como aderir a processos em projetos ágeis a utilização do BDD, deixando de fora o aprofundamento em algumas questões técnicas de aplicação em testes automatizados ou boas práticas a nível de escrita de cenários.
Como o BDD começou?
Quando falamos de BDD precisamos lembrar de um cara famoso (ou não) e sua criação, Kent Beck e Extreme Programming ou “XP”, em meados de 1999.
Ele propôs este modelo de desenvolvimento ágil de software pautado em alguns valores e boas práticas.
Dessas boas práticas e valores nasce o Test-Driven Development (TDD), com a premissa de que tudo deve ser testado antes de ser desenvolvido.
Falhar e refatorar até passar, assim seria possível garantir que o que foi solicitado seria entregue no final, e testado.
Bom, mais ou menos.
Devido à dificuldade em padronizar a comunicação entre as áreas, existe sempre a possibilidade de o entendimento ser parcial de um desenvolvimento.
Em resposta a isso, Dan North em 2004 surge com o BDD.
>>Leitura Recomendada:
Metodologia Lean: o que é e como usar na gestão?
Behavior Driven Development
BDD é uma metodologia de desenvolvimento ágil que foca no comportamento esperado de um sistema segundo seu requisito de negócio explícito, utilizando práticas de levantamento de requisitos como “User story” e “critérios de aceitação”.
O foco é a confirmação do entendimento dos requisitos de negócio por todos os envolvidos no projeto (Stakeholders, equipe de negócios e equipe de desenvolvimento), permitindo que tudo seja validado desde a elaboração das estórias de usuários até a codificação e usabilidade.
>>Leitura Recomendada:
Metodologia Scrum: tudo o que um DEV precisa saber
Behavior Driven Development e Agile
Não é só uma estrutura de escrita que caracteriza a metodologia, mas principalmente a formalização de todos os acordos entre os envolvidos no desenvolvimento para gerar comportamentos da funcionalidade.
Para que possamos utilizar o BDD de uma melhor forma, precisamos entender como englobá-lo nas estruturas propostas dentro da metodologia ágil.
>>Leitura Recomendada:
Automatizando Testes com Python, Selenium e Behave
Estrutura e descrição de funcionalidades
Para iniciação do desenvolvimento, começamos com a criação da User Story (ou Estória de usuário), que é um artefato do desenvolvimento utilizado em projetos geridos com metodologias ágeis.
Uma estória de usuário não deve ser depender de outra, deve ser negociável, de forma que possa alterar sua prioridade de execução com o cliente.
Deve entregar valor, deve ser estimável, deve ser pequena (para ser estimável), e deve ser testável (Conceito I.N.V.E.S.T).
Para a equipe responsável por extrair requisitos dos stakeholders (Analistas de negócios, P.O.), fica mais claro o entendimento da necessidade, pois é possível através dos passos de cenários imaginar a funcionalidade e propor um protótipo alinhado com a necessidade do cliente.
Outro ponto é que, além de entender melhor a necessidade, é possível a avaliar a prioridade e o valor de uma entrega.
Em relação à equipe de desenvolvimento, quando tratamos de uma pequena atividade que possui ao menos o “caminho feliz” descrito, pensar as infinitas possibilidades que precisam ser tratadas torna-se mais fácil.
E a equipe passa a prevenir problemas ao invés de corrigir.
E se, é possível imaginar os diversos problemas para o desenvolvimento, será eminente a certeza ao estimar horas para a execução e entrega.
Para poder ser testável, utilizamos Critério de aceitação (ou Gherkin), escritos em linguagem universal. Iniciando com as pré-condições (Given / Dado), seguindo por uma ação (When / Quando) é possível chegar a um comportamento como resultado esperado (Then / Então).
Obtendo então o seguinte resultado:
Funcionalidade:
Compra de produtos
Eu, como comprador na ferramenta de e-commerce, desejo que seja oferecido frete grátis para minhas compras acima de R$ 100, quando informar CEP da Região sul do Brasil.
Cenário 1:
Compra de um produto com frete grátis em região Sul do Brasil.
Dado que eu sou um cliente
Quando eu comprar um produto de qualquer categoria
E o valor total da compra for igual ou maior a R$ 100
E meu CEP pertencer a região Sul
Então eu vejo o frete grátis
Cenário 2:
Compra de um produto com frete grátis em região diferente do Sul do Brasil
Dado que eu sou um cliente
Quando eu comprar um produto de qualquer categoria
E o valor total da compra for igual ou maior a R$ 100
E meu CEP pertencer a região Sudeste
Então não terei o frete grátis
Mas frete deverá ser calculado para minha região
Priorização e Manutenção de Backlog
Se possuirmos uma atividade minimamente descrita com cenários, é possível visualizar seu impacto no produto final, e consequentemente priorizar dentro do backlog.
É possível avaliar se o levantamento de uma nova funcionalidade é coerente ao projeto no atual estágio, ou se faz sentido um novo desenvolvimento até aquele ponto, se comparar as funcionalidades existentes.
Nesse caso, com o BDD, se torna uma tarefa mais fácil de identificar similaridades do produto já desenvolvido com as atividades em planejamento através do comportamento descrito.
>>Leitura Recomendada:
Como aplicar Scrum em um projeto de teste de software?
Cerimônias de planejamento
Durante a Cerimônia de Planejamento do Scrum ou a Cadência de Reabastecimento do Kanban, pequenas atividades com cenários de aceitação possuindo as informações necessárias, permitem ao time responsável pelo desenvolvimento se concentrar em como solucionar o problema ao invés de passar boa parte apenas entendendo as especificações.
As estimativas estariam também sob controle.
Baseando-se nos cenários, é possível ter uma ideia da dificuldade para entrega dentro das datas estipuladas.
De um ponto de vista prático, se o time possuir profissionais de nível júnior, ou recém contratados, estes poderão se concentrar principalmente no comportamento esperado.
A regra de negócio está explícita nos cenários. A curva de aprendizado se torna bem menor usando BDD, possibilitando entregas mais frequentes e rápidas.
Mesmo que os cenários possuam apenas o fluxo principal para considerar a tarefa entregue, os integrantes da equipe podem também complementar os requisitos durante essas cerimônias de apresentação das atividades, por se tratar de uma linguagem comum a todos.
>>Leitura Recomendada:
Metodologia Agile, Scrum e Kanban: tudo sobre!
Desenvolvimento das atividades (work in progress)
Ao receber as novas funcionalidades com cenários de aceitação bem definidos, a prática do TDD torna-se mais fácil, o desenvolvimento de teste que deve falhar.
Está claro, permitindo uma refatoração para passar nos testes mais rápida e com maior qualidade não apenas por passar nos testes, mas por aplicar boas práticas presentes em design patterns.
Mesmo que não se utilize o TDD durante o desenvolvimento, fica mais claro o que precisa ser entregue.
Mas é aconselhado se pensar em possuir teste para garantir o entendimento e validação do desenvolvimento em relação ao resultado esperado.
No Behavior Driven Development os testes estão presentes em todos os ciclos do desenvolvimento, não só para codificação, mas pela experimentação da ideia desde sua concepção.
Mas para o desenvolvimento, não só os testes unitário e de integração são escritos, mesmo os de ponta-a-ponta.
Através de frameworks de interpretação de cenários como: Cucumber, Behat, JBehave, entre outros, podemos aplicar técnicas como ATDD, visando já possuir os testes de usabilidade prontos durante o período de testes que ocorrerá após entrega da atividade à equipe de validação.
Fica claro que os testes são parte importante da Metodologia, porém ainda que exista a crença de que testes automáticos gastem mais tempo do desenvolvimento, os resultados em menos retrabalhos ou bugs tornam-se visíveis.
Consequentemente, a qualidade tende a ser um ponto forte para aderir a estas boas práticas
Documentação
O que normalmente é uma dificuldade para o desenvolvimento de software, passa a ser parte presente do sistema a partir da automação de teste.
O documento é “vivo”, sempre sendo atualizado junto às funcionalidades e executável nas especificações de testes.
Entrega e validação com o cliente
Se conseguimos controlar a qualidade do que é entregue no final, possivelmente as estimativas estariam no prazo, e alinhadas com a necessidade do cliente.
Sendo direto, todos os custos para execução e entrega estariam também dentro do planejado.
Para o cliente, se todos os cenários forem validados por ele, existirá uma certeza maior de que atende às expectativas.
Conclusão
O Behavior Driven Development é uma ferramenta extremamente útil para projetos Ágeis de desenvolvimento de software.
Ainda que existam outras práticas para escrita de requisitos, o BDD permite imaginar a utilização da funcionalidade, facilitando a prototipação e alinhando as expectativas da equipe com o resultado esperado pelo stakeholder.
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.
Isso 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á a capacidade de estimar com maior precisão.
