Você trabalhou duro. Teclou em seu teclado até que tudo estivesse bem. Você se inclina para trás em sua cadeira, sorrindo. Sim, você está feliz com o resultado.
Alguns dias depois, seus ombros estão flácidos. O cliente não estava contente. Não é o que eles desejavam.
Que pena.
Mas anime-se, há uma resposta: Behavior Driven Development ou BDD para abreviar.
Continue lendo para saber o que é, como beneficia desenvolvedores, testadores e empresas, e o que implica em praticá-lo. Vamos começar com o que é.
Src: flatstack.com
A definição mais sucinta de Behavior Driven Development com a qual me deparei é esta:
BDD é um processo projetado para auxiliar a gestão e a entrega de projetos de desenvolvimento de software, melhorando a comunicação entre engenheiros e profissionais de negócios. Ao fazer isso, o BDD garante que todos os projetos de desenvolvimento permaneçam focados na entrega do que o negócio realmente precisa, atendendo a todas as exigências do usuário.
Sim, praticar BDD significa que você vai especificar e executar testes. Mas testar não é o objetivo.
Porque, assim como seu companheiro TDD (Test Driven Development), o BDD não se trata de testes. Trata-se de atingir as metas comerciais e os resultados do cliente no nível da aplicação. Assim como a definição tão claramente afirma.
Bem, com BDD você garante um software funcional sobre uma documentação abrangente no nível da aplicação e ainda obtém essa documentação.
Além disso, o Agile tem fortes raízes em eXtreme Programming. E Dan North – que originou o BDD – é um entusiasta de eXtreme Programming há muito tempo.
A ideia central no behaviour driven development é que nenhuma pessoa ou campo tem a resposta completa para qualquer coisa.
Você precisa de Três Amigos: profissionais de negócios, desenvolvedores e testadores para obter boas respostas.
Além disso, você precisa que eles colaborem. Porque é o ir e vir entre pessoas com diferentes estilos cognitivos e diferentes perspectivas e origens, que produz mágica. Mágica que lhe traz soluções melhores, mais simples e mais valiosas.
O que cada um dos Três Amigos traz para a mesa:
Quando você adota o Behavior Driven Development, você pode esperar estes benefícios:
No BDD você passa por três fases para cada história que deseja implementar.
As três fases são:
Estes seguem o padrão dado-quando-então:
o cenário (determinado) — o estado inicial, por exemplo, “o usuário está logado”,
o evento (quando) — o que acontece, por exemplo “o usuário pressiona o botão de logout”, e
o resultado (então) — a resposta esperada, por exemplo, “a página de login é mostrada”.
Software operacional: Os testes de aceitação guiam seu trabalho de implementação do software.
Um Exemplo BDD
Vamos passar pelas fases de Descoberta e Formulação para lhe dar um exemplo.
Título: Bloqueando outros usuários.
Narrativa: Como membro, quero bloquear usuários, para que eles não me incomodem mais.
A história parece simples o suficiente, mas as perguntas surgem assim que você começa a pensar bem nela:
A lista continua e continua.
Depois de conversar com o cliente, acontece que eles simplesmente não querem ver as atualizações de um usuário bloqueado em seu feed de atividades.
Portanto, fica com: como membro, quero silenciar os usuários, para que meu feed de atividades não mostre suas atualizações. Uma questão muito mais simples de resolver e muito menor no escopo.
Ainda assim, mesmo agora, não está totalmente claro o que precisa ser feito e o que não precisa ser feito. É hora de esclarecer com exemplos a partir da perspectiva do usuário.
Agora você escreve cada exemplo na notação estruturada que pode ser lida e executada por software.
Erros comuns em Behavior Driven Development são:
Behavior Driven Testing (BDT) é um processo menos conhecido que leva ao teste de aceitação automatizado. Assim como o BDD, ele promove a colaboração entre pessoas técnicas e não técnicas. E também usa uma linguagem natural formalizada para escrever testes que podem ser facilmente revisados e verificados por profissionais de negócios.
Mas o BDT se concentra mais no que os usuários fazem com o software. Ao invés dos critérios de aceitação que verificam a implementação da lógica empresarial.
Behavior Driven Development e Test Driven Development são similares e diferentes ao mesmo tempo.
A imagem acima ilustra como é difícil para um cliente descrever o que ele quer, e como fica deformado à medida que avança pelo caminho. É um clichê por uma razão, e um com uma longa história.
Mas usando o Behavior Driven Development, você pode fazer disso uma coisa do passado.
Sim, pode ser difícil parar e pensar, “perder” tempo tendo as conversas que o ajudarão a fazer isso.
Mas, vale a pena. Você vai criar um software útil que os clientes realmente querem, e você o fará sem ter que refazer, reparar ou retrabalhar o que já fez antes.
Contate-Nos hoje para uma demonstração personalizada do SwiftEnterprise! Ou inscreva-se para atualizações abaixo.
Solicitar Demonstração