O Desenvolvimento orientado por comportamento (BDD)
refere-se a uma técnica de desenvolvimento ágil, que
visa integrar regras de negócios com linguagem de
programação, focando o comportamento do software.
Tem como objetivo melhorar a colaboração entre
desenvolvedores, analistas de negócios e stakeholders,
para que todos possam ter uma compreensão clara das
expectativas em relação ao software. Para aplicar o
processo de BDD de forma eficiente, é necessário seguir
uma ordem específica, que inclui quatro etapas distintas,
caracterizadas a seguir.
I.É a fase em que o Product Owner explica a visão geral do negócio, na qual a equipe utiliza o processo de discussão do BDD para reunir exemplos de usuários e entender como a função fornecida é usada, identificando problemas e possíveis novas regras de negócios.
II.É a fase em que a equipe faz perguntas para determinar quais regras, critérios de aceitação ou novas histórias podem ser criadas, na qual o esclarecimento das ideias ocorre por meio do diálogo entre os participantes.
III.É a fase em que todas as questões discutidas são agrupadas, criando um documento que contém todas as notas reunidas, na qual a linguagem Gherkin é geralmente recomendada ao criar critérios de aceitação.
IV.É a fase em que após pesquisar e testar a história, a equipe de desenvolvimento apresenta ao Product Owner para validação, na qual a história validada é utilizada durante a revisão da produção do projeto, para garantir que o produto corresponda aos padrões estabelecidos. Para finalizar, após a instalação do aplicativo no ambiente de produção, ocorre o monitoramento da funcionalidade para coletar feedback do cliente sobre o sistema desenvolvido.
As etapas descritas são conhecidas, respectivamente, como:
I.É a fase em que o Product Owner explica a visão geral do negócio, na qual a equipe utiliza o processo de discussão do BDD para reunir exemplos de usuários e entender como a função fornecida é usada, identificando problemas e possíveis novas regras de negócios.
II.É a fase em que a equipe faz perguntas para determinar quais regras, critérios de aceitação ou novas histórias podem ser criadas, na qual o esclarecimento das ideias ocorre por meio do diálogo entre os participantes.
III.É a fase em que todas as questões discutidas são agrupadas, criando um documento que contém todas as notas reunidas, na qual a linguagem Gherkin é geralmente recomendada ao criar critérios de aceitação.
IV.É a fase em que após pesquisar e testar a história, a equipe de desenvolvimento apresenta ao Product Owner para validação, na qual a história validada é utilizada durante a revisão da produção do projeto, para garantir que o produto corresponda aos padrões estabelecidos. Para finalizar, após a instalação do aplicativo no ambiente de produção, ocorre o monitoramento da funcionalidade para coletar feedback do cliente sobre o sistema desenvolvido.
As etapas descritas são conhecidas, respectivamente, como: