Requisitos ágeis com BDD

O que você sabe sobre BDD?

Acha que é somente automação de testes? Vamos decifrar…

A tradução de BDD (Behavior Driven Development – Desenvolvimento Guiado por Comportamento), onde o software é construído de fora para dentro (outside-in). Da perspectiva do usuário, com menos desperdício.

BDD é primariamente a especificação executável e a aplicação das técnicas de extração de requisitos em uma linguagem mais informal e clara. Mas muita gente associa o BDD apenas à especificação executável, ou seja, em criar um cenário em Gherkin com o máximo de detalhes para automatizar testes. Isso é apenas uma consequência que pode ou não ser aplicada. Por esse motivo, muitas pessoas deturpam o conceito. Elas querem usar o BDD apenas para automatizar teste. Esquecem-se que o BDD auxilia na concepção e planejamento da solução também; garantindo maior qualidade as entregas para o cliente.

BDD propõe uma forma eficaz de resolver problemas de comunicação entre as equipes de negócio (cliente e Product Owner) e técnica (desenvolvimento e testes),  aumentando o compartilhamento de conhecimento entre elas. Outra grande vantagem, é a documentação dinâmica. Algumas equipes ágeis dizem que o processo de documentar software é demorado.

É comum ouvirmos:

– Times de desenvolvimento no estilo cascata [2] costumam escrever documentos verbosos que os desenvolvedores odeiam ler e têm dificuldade de entender.

– Times ágeis trabalham no lado oposto, escrevendo estórias de usuários sem muita informação.

O BDD ajuda nessa discrepância entre o muito e o pouco.

Umas das técnicas utilizadas no âmbito dos requisitos ágeis é o uso de BDD para refinar o backlog. A prática principal do BDD é escrever as funcionalidades em forma de cenários numa linguagem ubíqua. E para validar esses cenários, escrevemos os critérios de aceite da aplicação.

Uma forma de descrever o comportamento do software utilizando a linguagem natural seria descrever primeiro a estória e em seguida o cenário. Segundo Dan North [1], seguir esse padrão facilita a comunicação entre os envolvidos no projeto. Não é necessário nenhuma ferramenta. A linguagem utilizada para documentar o comportamento é uma narrativa seguindo o modelo:

Como (papel)

Eu quero (funcionalidade)

Então (beneficio/resultado)

O cenário é descrito por critérios de aceitação na seguinte forma:

Cenário : [Descrever o cenário]

Dado que [ Estado inicial do sistema ]

Quando [ Ação a ser realizada no sistema ]

Então [ Coisas que o sistema deve fazer após a ação do Quando ]

Os requisitos devem ser capturados como comportamentos, resultando numa lista de ‘especificações do comportamento’. Na verdade, isso que é levantamento de requisitos. Deve-se definir o que o software deve fazer (modo de agir) e ajustar ele no contexto de valor do negócio [2]. Você escreve cenários de teste em alto nível seguindo uma estrutura e chama a aplicação para o teste de aceitação. Tanto a abordagem de requisitos ágeis quanto de BDD podem ser usados como uma estratégia para a organização. A ideia é ter um retorno sobre o produto a ponto de conseguir posicionar ele de forma mais assertiva dentro do mercado.

 Referências:

[1] http://www.devmedia.com.br/desenvolvimento-orientado-por-comportamento-bdd/21127

[2] http://neelnarayan.blogspot.com.br/2011/04/bdd-is-not-about-tools.html

Por MAGDA IOLANDA FARIA

Analista de Requisitos, MATERANA desde 2011, adepta a experimentar novidades e cervejas. Nas horas de lazer acha que é corredora.

Postado em: 28 de junho de 2017

Confira outros artigos do nosso blog

Como a comunicação influencia em times ágeis?

15 de junho de 2018

Ariane Ferreira Izac

Vamos falar sobre métricas Kanban?

21 de maio de 2018

Ricardo Augusto Shikota

Método Kanban: primeiros passos

10 de maio de 2018

João Paulo Grabosque

Afinal, o que é Scrum Master?

20 de abril de 2018

Fernanda Rogge Barbosa

Deixe seu comentário