Sem entender, não dá para trabalhar com BDD.
Tenho visto alguns relatos expressando o descontentamento com a utilização do BDD, mas muitas pessoas que utilizam essa abordagem deixam de lado alguns pontos cruciais para o bom desempenho dessa metodologia. Vou apresentar três pontos que, se não forem bem alinhados, podem te levar a tal frustração.
Behavioral Driven Development (BDD) é uma abordagem de desenvolvimento de software orientada pelo comportamento e quase deve ser encarada como uma filosofia, que busca facilitar a comunicação entre as partes interessadas do projeto. Esse conceito foi apresentado por Dan North e ele sempre prezou pela aproximação de pessoas não técnicas no projeto, inclusive, ele afirma que um dos benefícios dessa abordagem é a visão coerente que existe entre as partes relacionadas do projeto.
Pontos que merecem atenção para não causarem frustração
Ponto 1– Se o seu cliente não é capaz de entender o que está sendo solicitado, você, provavelmente, não está escrevendo de forma adequada.
O BDD defende uma comunicação clara, o que está sendo escrito deve ser entendido por todos os envolvidos. Procure fugir dos jargões técnicos, a escrita clara aproxima todos os envolvidos do projeto. Na dúvida, não invente; o feijão com arroz funciona muito bem.
● Given — dado um contexto;
● When — quando acontecer um evento;
● Then — então se espera que aconteça algo.
Ponto 2 – Se apenas sua equipe de teste está utilizando BDD, você está desperdiçando uma grande força de trabalho, toda a equipe deve compartilhar dessa abordagem, caso contrário, mais cedo ou mais tarde as consequências vão chegar. A utilização apenas por parte da equipe acaba inviabilizando o projeto, a comunicação deve ser íntegra e menos volátil possível. Ou a equipe abraça o BDD, ou é melhor escolher outra abordagem. Que tal começar a pensar no BDD como uma cultura?
Ponto 3 – Não pense em um caso de teste, pense em aplicabilidade para os usuários. Muitas vezes o BDD acaba sendo direcionado apenas para a construção de casos de teste, mas o foco deve ser a funcionalidade que está sendo desenvolvida. Não custa lembrar que a metodologia é voltada ao comportamento do sistema, então pense no contexto do usuário e projete o comportamento da aplicação.
Ponto bônus – Que tal, durante a especificação de uma funcionalidade, utilizar a regra dos três amigos criada por George Dinwiddie? O conceito propõe que o PO (ou algum agente relacionado ao negócio), Desenvolvedor e Tester devem ser envolvidos na definição da funcionalidade, com isso será possível ter três perspectivas distintas e alinhadas o mais rápido possível.