O ciclo de vida das Aplicações caracteriza-se por uma crescente exigência, por parte dos seus utilizadores/clientes, com cada vez mais requisitos e pedidos de alterações. Este contexto acarreta vários desafios que as Organizações terão de ser, imperativamente, capazes de responder.
A implementação de uma metodologia de qualidade, capaz de garantir as expetativas dos utilizadores/clientes seja cumprida, assume particular importância na implementação de ciclos de desenvolvimento cada vez mais curtos.
O grande desafio dos projetos, no processo de levantamento de requisitos, é a identificação da solução, em vez da necessidade. Por norma, o utilizador identifica o que gostaria de ver na aplicação (ex: um novo report, novo botão), em vez de identificar a necessidade ou o comportamento esperado. E com base nesse requisito, cabe aos Analistas Funcionais e Técnicos fazerem a sua análise e identificar a melhor solução, quer em termos custo\benefício, quer no alinhamento com a arquitetura/estratégia do IT. Sem a necessidade identificada, é mais complexo definir a melhor solução a implementar, quer em termos de valor para o negócio, quer em custos de implementação.
Com estas ambiguidades, aquando do processo de levantamento de requisitos, orientado à solução, e com a agravante de uma linguagem díspar, entre as áreas de negócio e as áreas de desenvolvimento, o processo de qualidade afigura-se como sendo a chave, para garantir a correta compreensão de todos os stakeholders do projeto.
Behavior Driven Development
Como podem os processos de qualidade ajudar na implementação do BDD?
Os processos de qualidade, quando implementados no início dos projetos e no momento da definição dos requisitos, permitem seguir o BDD para descrever casos de testes, cenários de comportamento, questionar a área de negócio e identificar todos os comportamentos que serão necessários desenvolver pela área de desenvolvimento. Esses cenários devem ser sempre descritos com a mesma linguagem, garantindo um mútuo entendimento por todos os stakeholders do projeto.
Esta linguagem simples, denominada por Gherkin, é composta pelas seguintes sintaxes: Given – etapa utilizada para estabelecer a pré-condição/contexto do cenário de teste; When – etapa em que se descreve um evento ou uma ação; Then – última etapa do cenário de teste que descreve o resultado esperado das ações acima. Deve utilizar uma verificação para comparar o resultado esperado com o resultado obtido; Finalmente, And – quando a afirmação da palavra-chave (Given,When,Then) não é suficiente, sendo utilizado para acrescentar mais informação.
Ao realizar múltiplos cenários, na fase de requisitos, garante-se que a fase de desenvolvimento será menos ambígua, permitindo à equipa de desenvolvimento uma entrega mais célere e com menos pedidos de alteração. Por outro lado, como o negócio sabe antes do desenvolvimento os comportamentos que vão ser desenvolvidos e testados, o volume de bugs abertos, por má definição de requisitos, será substancialmente menor.
Segundo a nossa experiência, com a implementação desta framework, é possível garantir reduções na ordem dos 30% de abertura de bugs na fase de testes e uma diminuição de interações na fase de desenvolvimento, para esclarecimento de dúvidas. Outro indicador relevante é a redução de cerca de 50% dos pedidos de alteração após o Go Live.
Há ainda que ter também em conta as vantagens do BDD no processo de automatização. Com os casos de testes descritos em Gherkin, e geridos pelos owners do processo de qualidade, o processo de automatização torna-se mais célere e simplificado, utilizando frameworks de automação que suportam linguagem BDD (ex: Cucumber, Robot Framework, BDD Framework, etc).
Atualmente, é cada vez mais importante que a bateria de regressão esteja automatizada, garantindo rapidez no feedback do processo de testes e aumento da “cobertura” da equipa de qualidade.
Assim, a interação entre os tester manuais, que são owners do processo de qualidade e garantem que os testes são executados com sucesso (independentemente se a execução é manual ou automática), e os testers de automação está simplificada, porque partilham a mesma linguagem. Esta partilha de uma mesma linguagem permite que o processo de criação de automatismos seja mais célere, mas também, que o processo de manutenção seja muito mais reduzido, uma vez que quando o caso de teste falha, o tester, consegue identificar a razão e perceber se a falha da execução se deve a um erro funcional ou a uma necessidade de manutenção dos automatismos.
A implementação de automação baseado em BDD, reduz significativamente os automatismos construídos sem que haja retorno na sua execução. Todos os automatismos criados, são fundamentados numa especificação de um teste manual, e a sua execução automática fica associada sempre a esse caso de testes. Assim torna-se possível, através de ferramentas de ALM (Jira, Azure Devops), verificar o número de execuções automáticas efetuadas, analisar execução e as evidências das mesmas.
Em suma, investir no processo de qualidade e na framework BDD, garante eficiência em todo o ciclo de vida de desenvolvimento de uma organização.
O Pplware agradece ao Diogo Soares, Quality Senior Manager at Noesis pela escrita do artigo.