Desenvolvedores, testadores, gerentes de produto, gerentes de negócios e usuários, geralmente têm diferentes pontos de vista sobre o que faz um ótimo software. Isso pode levar a gargalos e retrabalho desnecessário, o que aumenta o custo e frustra os responsáveis. Em última análise, porém, o software deve atender às expectativas do usuário/cliente e atender aos objetivos do negócio.

É aí que o desenvolvimento orientado por comportamento (Behavior-Driven Development (BDD) entra em ação. Essa metodologia de desenvolvimento nasceu da necessidade de colocar os comportamentos desejados de um recurso em primeiro lugar, e as ferramentas e processos do BDD ajudam a manter todos os interessados na mesma página, usando o Português simples.

Um breve resumo de como o BDD funciona

Ao contrário da unidade de desenvolvimento tradicional ou dos scripts de teste funcional, os scripts BDD são escritos na forma de cenários de uso reais a partir da sintaxe Gherkin “Given-When-Then”, adotada por ferramentas populares de BDD, como o Cucumber.

Um exemplo:

Recurso: entrar
Considerando que eu tenho um nome de usuário [SITENAME] e senha
Eu deveria poder entrar em [SITENAME]
Se meu nome de usuário e senha estiverem corretos
Cenário: ativar a redefinição de senha
Considerando que me inscrevi para [SITENAME]
E eu nunca entrei em [SITENAME] depois de 90 dias
Quando insiro meu nome de usuário e senha existente para fazer login
Então eu deveria ser notificado e solicitado a mudar minha senha

Qualquer pessoa, desde engenheiros a proprietários de produtos (product owners), pode escrever cenários de BDD, porque eles estão escritos em linguagem para leigos. O comportamento desejado é documentado no arquivo de recurso e os testes são automatizados para validar os cenários de negócios que você deseja criar.

Em um nível mais elevado, o BDD força as partes interessadas a trabalharem juntas porque a equipe inteira está rastreando seus critérios de teste, código e aceitação para o arquivo de recurso. Por exemplo, quando um teste falha, o desenvolvedor deve concordar que ele está falhando porque não corresponde ao comportamento do sistema que está sendo desenvolvido.

O BDD se concentra na velocidade e na qualidade, o último dos quais tem sido uma fraqueza dos DevOps. Na melhor das hipóteses, o BDD elimina a acusação (finger-pointing ) quando algo dá errado durante o desenvolvimento ou pós-produção.

O BDD nasceu do desenvolvimento orientado a testes (TDD), que tem tudo a ver com testes unitários. O BDD leva o TDD para o próximo nível, concentrando-se nos cenários e na experiência do usuário, além de verificar se o código está funcionando corretamente e não quebra nenhum outro código não correlacionado.

Benefícios empresariais do BDD

O BDD é ótimo para os desenvolvedores porque os cenários se concentram em como o recurso deve se comportar para o usuário, o que significa menos ambiguidades no processo. Outro benefício importante é que é mais fácil transformar esses cenários em testes automatizados usando a sintaxe do Gherkin. Mesmo que os benefícios do negócio tenham sido discutidos com menos frequência, eles não deixam ser menos importantes.

1. Maximiza os recursos e minimiza o desperdício

As partes interessadas nos negócios se preocupam com movimentos competitivos que podem prejudicar o crescimento das receitas ou afastar clientes. Portanto, quando se trata de trabalhar com a equipe de desenvolvimento, os profissionais de negócios querem aumentar a velocidade de lançamento do produto no mercado (time-to-market), ao mesmo tempo em que oferecem uma experiência de usuário realmente incrível.

O BDD não é a “bala-de-prata”, mas limita o retrabalho de um recurso porque as ferramentas do BDD (como o Cucumber), permitem que uma equipe multifuncional defina com facilidade e clareza a experiência do usuário logo no início do ciclo de DevOps.

Isso ajuda a focar o projeto e impedir a introdução de recursos que não são relevantes para a base de usuários. O BDD também fala com o componente de velocidade de duas maneiras: evitando gargalos e diminuindo os testes manuais.

2. Melhora a comunicação para alcançar objetivos compartilhados

DevOps se propôs a melhorar os processos de desenvolvimento para que ele seja mais colaborativo, ágil e rápido. Ainda assim, muito é deixado ao acaso quando se trata de comunicação e colaboração entre diferentes papéis e atores. O BDD incentiva mais automação de teste e um processo que inclui funcionários não-desenvolvedores.

O legal é que, embora o processo “três amigos” se concentre na colaboração entre um testador, desenvolvedor e gerente de produto, o BDD poderia incluir outros papéis também, como um analista de negócios ou um líder de controle de qualidade (Quality Assurance, QA).

Ter mais atores com diversas perspectivas pode garantir o alinhamento no início e, em última análise, produzir um software de maior qualidade, especialmente com um projeto complexo ou de alto risco.

3. Possibilita fornecer software de alta qualidade e alinhado com os objetivos de negócios

Qualidade é um termo subjetivo. O que o BDD traz é uma concordância explícita sobre essa noção de qualidade entre pessoas que, por vezes, se opõem a espectros do ciclo de vida do produto. O BDD suporta maior automação, o que aumenta a velocidade de teste e a cobertura, mas nunca perde os critérios de aceitação ou a visão inicial do produto.

Embora nunca seja fácil mudar para um processo totalmente novo, vemos a adoção do BDD acelerar várias empresas. Uma que eu conheço foi capaz de minimizar defeitos e acelerar o time-to-market depois de mudar para o BDD.

A equipe de Quality Assurance desta empresa lutou para definir os cenários de teste corretos com base nos requisitos de negócios, já que o controle de qualidade, os desenvolvedores e os product owners nunca foram reunidos em sessões de planejamento de sprint quando as histórias de usuários eram gravadas. Os testadores muitas vezes nem sequer os viram até o desenvolvimento ter começado.

Agora, os testadores participam de todas as sessões de planejamento de sprint e podem escrever casos de teste ao lado de product owners e desenvolvedores. Isso não apenas garante que os product owners possam ver as interpretações de requisitos dos desenvolvedores e testadores e corrigir mal-entendidos em tempo real.

A equipe inteira também gasta seu tempo com muito mais eficiência, pois todos concordaram com o que desenvolver antes. E, como eles usam uma estrutura de BDD, os cenários testados por eles podem ser facilmente traduzidos em testes de scripts de teste automatizados, o que economiza um tempo significativo no processo de teste.