BDD simplificado

Por: Renato Stancato; Rafael Fernandes Batistella; Leonardo Angelo e Silva Furlan

 

Caso você já tenha tentado aplicar a metodologia BDD e tenha encontrado dificuldades na automação dos testes antes de iniciar o desenvolvimento ou tenha enfrentado resistência por parte da equipe em modificar a forma como se escrevem os documentos de requisitos (ou por qualquer outro motivo), este artigo pode ser um excelente ponto de partida para se obter uma grande parte dos benefícios do BDD com impactos mínimos no fluxo de trabalho e na produção de artefatos.

Quando se trata da metodologia de desenvolvimento orientado a comportamento (BDD – Behavior Driven Development), é comum associá-la à criação de cenários de teste automatizados utilizando a técnica Given-When-Then, que são definidos previamente à codificação. Entretanto, ao aprofundar nossa compreensão sobre os benefícios desta técnica, é possível perceber que a automação dos testes é apenas uma parte do processo – não necessariamente a mais relevante, dependendo do contexto. Uma metodologia,  técnica ou ferramenta, pode ser adaptada para o seu contexto e ainda assim tirar o máximo proveito sem comprometer seus conceitos fundamentais.  

Como principais ganhos do BDD podemos destacar:  

• Entendimento comum dos requisitos de negócio 
• Capacitação da equipe 
• Definição clara do status “Pronto” 
• Identificação prévia de defeitos 
• Melhoria na qualidade da entrega 
• Criação de testes automatizados 

Entendimento comum dos requisitos de negócio

Quando reduzimos significativamente o intervalo de tempo entre a definição dos requisitos no início do projeto e a criação e execução dos cenários de teste no final, conseguimos minimizar consideravelmente as possíveis falhas de comunicação. Ao envolver o responsável pela escrita dos requisitos desde o início na elaboração dos cenários de teste, ou permitir que isso seja feito em colaboração com o profissional de testes, torna-se muito mais fácil compreender o que precisa ser feito, eliminando a dificuldade de interpretação e entendimento do que foi solicitado.

Capacitação da equipe 

É comum que nem todos os membros da equipe possuam o mesmo nível de conhecimento do negócio ou do problema do cliente. O profissional de requisitos, geralmente, é quem possui um entendimento mais profundo desses aspectos. Quando trabalhamos com a especificação conjunta de requisitos e cenários de uso, esse artefato se torna extremamente valioso e pode ser utilizado como referência para a capacitação de todo o time. Dessa forma, é possível nivelar o conhecimento da equipe, aprimorar a compreensão do problema do cliente e promover uma melhor sinergia entre os integrantes do projeto.

Definição clara do status “Pronto” 

Para um desenvolvedor, definir o momento adequado para encerrar os testes unitários é uma tarefa bastante complexa. É comum surgirem dúvidas sobre testar o máximo possível dentro do tempo disponível, testar apenas o que se conhece ou focar somente no “cenário feliz”. Com a metodologia BDD, o implementador tem clareza sobre quando concluiu sua tarefa, uma vez que sua missão é codificar e corrigir até que todos os cenários especificados sejam executados com sucesso. Além disso, o BDD oferece maior facilidade na definição de critérios de aceitação, utilizando uma linguagem clara e sem ambiguidades, e proporciona maior flexibilidade para a especificação de regras, desde as mais simples até as mais complexas. É possível definir cenários mais descritivos e simples, bem como cenários mais impositivos e complexos, de acordo com a necessidade do projeto.

Identificação prévia de defeitos 

Sabemos que quanto mais cedo um defeito for identificado num fluxo produtivo (seja ele qual for) o custo de correção é mais barato. Portanto, se realizamos todos os testes conhecidos enquanto estamos codificando, o custo da correção é extremamente menor do que quando corrigimos após a identificação de um defeito pelo profissional de testes. 

Melhoria na qualidade da entrega 

Quando elaboramos as histórias do usuário e os cenários de uso antes de iniciar a implementação podemos inclusive realizar esta atividade em conjunto com o cliente (de preferência com o usuário final) ou pelo menos solicitar suas contribuições já que neste caso a escrita em BDD facilita a compreensão. Assim, as surpresas são bem menores para todos após a entrega. 

Criação de testes automatizados 

Realizar qualquer alteração no código fica mais confortável quando podemos executar um conjunto de testes automatizados para ajudar a identificar se introduzimos defeitos. No final da execução de uma entrega com BDD, além de todos os benefícios mencionados, dispomos de um conjunto de testes que poderão ser realizados de forma automática sempre que necessário para “proteger” o que foi entregue em releases anteriores contra novos defeitos. 

Importante ressaltar que recomendamos a aplicação do BDD como foi descrita originalmente sempre que possível. Mas também acreditamos que um pequeno benefício hoje sem muito esforço investido pode significar um benefício enorme no futuro. Portanto, também apoiamos “começar” com o que temos quando não podemos fazer tudo o que é necessário para melhorar nossa produtividade.  

Para começar a se beneficiar desta prática, mesmo sem poder criar testes automatizados num primeiro momento, é preciso garantir apenas que o plano (roteiro, cenários, etc…) de testes – documento-guia dos testadores durante os testes sistêmicos – seja construído na sequência ou até mesmo em conjunto com os requisitos do negócio (Use Cases, Histórias do Usuário, etc.). 

Com os casos de testes definidos (por alguém que entenda bem do negócio) em uma planilha (ou qualquer outro meio) o implementador pode codificar e executar todos os casos de testes que seriam feitos pelo tester durante a codificação. 

Escrevemos os requisitos, em seguida escrevemos o roteiro de testes, revisamos os dois artefatos incluindo um dos mais experientes que vai implementar e somente depois disso inicia-se a implementação, que deve utilizar o roteiro de testes como guia para suas validações que, por sua vez, devem ser realizadas antes do profissional de testes. 

Desta forma, o profissional de testes pode se concentrar em validações bem mais avançadas: performance, segurança, escalabilidade, usabilidade, dentre outras. 

No início, pode haver um aumento no esforço dos implementadores, pois muitos não estão familiarizados com testes mais elaborados ou não têm um conhecimento profundo da aplicação que estão desenvolvendo. Contudo, esse acréscimo é compensado por uma entrega de maior qualidade na fase de testes. Isso, por sua vez, leva a uma redução no custo geral do ciclo de produção, pois se evita o retrabalho gerado por correções em várias rodadas de testes e implementações.

 

Referências

[1] – https://cucumber.io/

[2[ – https://en.wikipedia.org/wiki/Behavior-driven_development