Home  >  Negócios

BDD: como o Behavior-Driven Development pode melhorar o alinhamento dos negócios

Metodologia de desenvolvimento nasceu da necessidade de colocar os comportamentos desejados de um recurso em primeiro lugar

Ryan Yackel*

11/10/2018 às 14h10

gestão negócios
Foto: Shutterstock

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 na 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 deixar ser menos importantes.

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.
(1) O Behavior-Driven Development, BDD, traduzido como desenvolvimento orientado por comportamento, é uma técnica de desenvolvimento Ágil impulsiona a laboração entre desenvolvedores, setores de qualidade e pessoas não-técnicas ou de negócios em projeto de software. Seu uso está em expansão nas organizações que buscam entregar melhores software alinhados aos desejos de seus clientes.
(*) Gerente de produto da QASymphony, fornecedora de ferramentas de testes de software.