Desenvolvimento Orientado a Comportamento com Testes
Automatizados utilizando JBehave e Selenium
Rafael B. Chiavegatto¹, Lidiane V. da Silva², Andréia Vieira², William R. Malvezzi¹
¹Centro de Pós-Graduação e Extensão (CPGE) – Faculdade FUCAPI – Manaus – AM – Brasil
²Fundação Desembargador Paulo dos Anjos Feitoza (FPF) – Manaus – AM – Brasil {rafael.chiavegatto, lidiane.silva, aviera}@fpf.br,
william.malvezzi@fucapi.br
Abstract. With a view to the continuous improvement of the software development process, this paper presents the application of the technique of test automation using frameworks to optimize the execution of the process activities, implementing the methodology Behavior Driven Development (BDD), aiming at the common language, participatory collaboration between those involved in the process of developing quality software.
Resumo. Tendo em vista a melhoria contínua do processo de desenvolvimento de software, este artigo apresenta a aplicação da técnica de automatização de testes utilizando frameworks para otimizar as atividades de execução do processo, implementando a metodologia Behavior Driven Development (BDD), visando à colaboração participativa em linguagem comum, entre os envolvidos no processo de desenvolvimento de software qualitativo.
1. Introdução
A partir do final dos anos 90 do século passado, as empresas que desenvolvem software vêm buscando a garantia da qualidade dos sistemas desenvolvidos, por meio de estudos sobre técnicas e metodologias a fim de aplicá-las para melhoria do processo de desenvolvimento, objetivando a qualidade dos seus produtos.
[...] teste de Software é uma área que tem crescido significativamente nos últimos tempos, em especial a técnica de automatização de testes. Esta abordagem está cada vez mais em evidência devido à agilidade, eficácia, baixo custo de implementação e manutenção, funcionando como um bom mecanismo para controlar a qualidade dos sistemas [...]. (BERNARDO, 2011).
Todavia, é necessário o mínimo de conhecimento sobre a área para evitar falhas comuns no processo de desenvolvimento das atividades, como erros na escrita dos scripts dificultando sua manutenibilidade. Quando os testes automatizados são de baixa qualidade, tendem a não contribuir para o controle da qualidade de um sistema e geram uma demanda maior de esforço na fase de testes.
Com intuito de suprir essas necessidades, este artigo apresenta a adoção da técnica de automatização no processo de teste de software (criação, manutenção e
gerenciamento dos casos de testes automatizados), utilizando a metodologia Behavior Driven Development (BDD), fazendo com que cada um dos envolvidoss contribua para melhoria contínua da qualidade, com a finalidade de tornar o processo de teste mais eficiente e produtivo.
2. Referencial teórico
2.1. Teste e Qualidade de Software
No processo de desenvolvimento de software, testar deve tornar-se um hábito, de forma a garantir a qualidade dos produtos desenvolvidos. A atividade está ligada diretamente à qualidade, pois, para obtenção de um software de que atenda as expectativas do cliente, é necessário que seja realizado um conjunto de testes específicos.
Schwaber e Beedle afirmam que
“metodologias de desenvolvimento ágeis como Scrum, recomendam que todas as pessoas envolvidas em um projeto trabalhem controlando a qualidade do produto todos os dias e a qualquer momento, pois baseiam-se na ideia de que prevenir defeitos é mais fácil e barato que identificá-los e corrigi-los a posteriori.” (apud BERNARDO, 2001).
Inthurn (2001) ainda complementa, “teste de software tem como objetivo aprimorar a produtividade e fornecer evidências de confiabilidade, em complemento a outras atividades de garantia de qualidade ao longo do processo de desenvolvimento do software.”
Dessa forma, testar é um processo de repetição contínua de passos para analisar se os requisitos e as condições funcionais e não funcionais especificadas, foram implementadas de fato, bem como detectar erros e identificar falhas. Sommerville (2003) afirma que, “[...] os testes constituem uma fase dispendiosa e trabalhosa do processo [...]”. A execução manual de um caso de teste é rápida e efetiva, mas a execução e repetição de um vasto conjunto de testes é uma tarefa árdua e cansativa.
Dado esse cenário, utilizar meios automáticos para execução desta etapa de desenvolvimento pode agregar ganho de tempo para a Organização. Devido a tal fato, a automatização de testes vem sendo utilizada como uma forma de evitar esse problema, com a substituição parcial dos testes manuais, diminuindo os custos de produção do software através da agilidade que os testes automatizados proporcionam.
2.2. Automatização de testes
A introdução de testes automatizados no processo de desenvolvimento remete a iniciativa de melhoria da qualidade dos software. A automatização de testes possui o objetivo de apoiar o processo, reduzindo ou eliminando gargalos no tempo de execução, entretanto esse processo vai além da escolha de uma ferramenta.
Segundo Maldonado et al (2007), “A técnica de automação é voltada principalmente para melhoria da qualidade, baseia-se fortemente na teoria de Teste de software, para aplicar as recomendações dos testes manuais na automação dos testes.”
Os testes automatizados tendem a ter uma maior produtividade, onde é necessário um esforço inicial que é compensando na execução a longo prazo. “O teste
manual não pode ser eliminado, deve sim, ser reduzido ao máximo possível e focado naquilo que é muito caro automatizar.” (MOLINARI, 2010).
A automatização de testes é uma prática ágil e eficaz para melhorar a qualidade dos software, porém inicialmente a adoção da técnica é mais custosa, pois, demanda um esforço maior de tempo e de mão de obra qualificada. É necessário conhecimento, organização e experiência para evitar que a aplicação dessa técnica não seja utilizada de forma incorreta, e para que não haja redução no custo-benefício dessa prática no desenvolvimento de software.
2.3. Behaviour Driven Development
Behaviour Driven Development (BDD) é uma das técnicas ágeis para desenvolvimento de software que estimula a colaboração entre os participantes de um projeto, trabalhando a comunicação de forma ubíqua, a fim de que os envolvidos falem a mesma linguagem e consigam compreender e contribuir para que os requisitos constantemente estejam atualizados, especificando estórias referentes às funcionalidades que futuramente poderão ser executadas.
É considerado que BDD é um aprimoramento de Test Driven Development (TDD). A principal diferença é a mudança de foco: de teste para comportamento. “Ao invés de escrever testes para verificar se um método faz o esperado, o desenvolvedor escreve especificações descrevendo o comportamento que a funcionalidade deve possuir.” (ASTELS, 2006).
O BDD visa minimizar a falha de comunicação entre os stakeholders envolvidos no projeto (cliente e equipe de desenvolvimento), uma vez que utilizando uma linguagem livre de termos típicos de teste. Os termos são comuns e unificados, propondo a descrição e atualização dos requisitos.
Há uma gama de ferramentas para apoiar o processo de BDD, para diversas linguagens de programação, todas seguindo a mesma abordagem. Dentre elas estão RSpec, Cucumber, JDave, BDoc e JBehave, que será utilizada nesse artigo.
2.4. JBehave
O JBehave é um framework de desenvolvimento orientado a comportamento, que permite criar especificações em linguagem natural ou seja, é possível escrever cenários exemplificando cada funcionalidade de modo que os envolvidos compreendam os critérios de aceitação dos cenários de teste, focando no comportamento do software.
Baseia-se em um arquivo texto projetado para conter os cenários de uma estória de um determinado usuário. Essas estórias são descritas em formato de passos detalhados, de forma que um usuário que não detenha conhecimento e perfil técnico sobre software possa compreender, conforme Figura 1.
Figura 1. Exemplo de Especificação de cenário no JBehave Os cenários são compostos pelas seguintes notações:
Narrativa: Descrição da estória
Cenário: Descrição do cenário para estória
Dado que (Given) – São as pré-condições para executar o cenário
Quando (When) – São os testes (passos) para execução do cenário
Então (Then) – É o resultado esperado da execução dos passos.
“O JBehave em si é um plugin do JUnit (framework de testes de unidade) e as especificações criadas para os passos devem ser mapeadas para testes de unidade reais.” (SANTOS, 2010). Em nível de especificação de cenários, o mapeamento serve para parametrização de passos, o que facilita na reutilização para a criação de novos arquivos de texto ou outros cenários de teste.
A especificação é salva em um arquivo com extensão .story, que posteriormente será interpretado pelo JBehave seguindo o mapeamento realizado. O mapeamento instrui como o JBehave deve ler o arquivo de especificação e como criar um teste a partir dele.
Para cada arquivo de cenários (.story), deve existir um arquivo .java contendo o respectivo mapeamento. Para ser elaborado é necessário à utilização das anotações: @Given, @When e @Then. As palavras chaves parametrizadas iniciadas com o símbolo: $, significam que será passado por parâmetro o valor (destacados em vermelho no arquivo .story da Figura 1) para o método correspondente no arquivo .java, conforme mostra Figura 2:
Figura 2. Classe .java contendo o mapeamento dos cenários no JBehave
Depois de realizado o mapeamento é possível utilizar um framework de testes para a execução dos cenários, nesse caso será utilizado o JUnit. O JBehave possui uma
classe própria para essa associação, bastando criar uma classe e estendê-la à classe JUnitStory. Ao executá-la como JUnit Test serão executados os testes dos cenários elaborados.
A classe de configuração possui: o idioma que deve ser interpretado os cenários, a localização de onde estão os cenários especificados e o formato que será gerado os relatórios, conforme exibido na Figura 3.
Figura 3. Exemplo de arquivo de configuração do JBehave
O JBehave é um framework muito utilizado pela comunidade Java, sua documentação é bem vasta e de fácil entendimento. Muitos blogs e fóruns de discussões fornecem informações sobre sua utilização e configuração.
2.5. Selenium
Conforme visto, as funcionalidades do sistema são representadas por estórias e dessas são extraídos os testes de aceitação, que são automatizados por um framework de automatização de testes.
O Selenium é um framework open source, utilizado para automatização de testes funcionais em aplicações web. “[...] os testes podem ser executados em praticamente todos os navegadores existentes e uma vantagem é que eles podem ser escritos em diversas linguagens de programação, tais como: Java, C#, Python, PHP, Perl, HTML e Ruby.” (Gonçalves, 2011).
2.6. JUnit
O JUnit é um framework open source para utilização de testes unitários em Java, sendo possível criar classes de testes que podem ter um ou mais métodos para execução. Os testes podem ser executados sequencialmente ou de forma modularizada, dessa forma, os sistemas podem ser testados em partes ou de uma única vez.
Conforme Hunt e Thomas (2003), “Em 1998, Kent Beck e Erich Gamma desenvolveram o arcabouço JUnit para a linguagem Java, inspirado no SUnit.” Desde então a prática de testes automatizados vem sendo disseminada dentre as equipes de desenvolvimento de software adeptas a automatização.
De forma geral seu funcionamento se dá através da verificação dos métodos de uma classe, constatando se os mesmos funcionam da maneira esperada, exibindo de forma visual o resultado da execução positiva ou negativa dos testes (Passed or Fail).
3. Estudo de Caso: Utilização de BDD com frameworks para automatização de testes
Nesse estudo de caso será utilizado um sistema para soluções hospitalares composto de nove módulos. O mesmo encontra-se em produção, porém continua sofrendo alterações em suas funcionalidades e constantemente é necessário passar por testes de regressão. Entretanto, por se tratar de um sistema grande e complexo, o esforço com esses testes tem sido custoso demandando esforço e tempo da equipe.
O cenário atual dos testes do sistema ocorre através de execução manual. São elaborados casos de teste funcionais, baseados nas especificações dos requisitos, conforme Figura 4.
Figura 4. Especificação de Caso de teste
A especificação dos casos de testes, não fornece todas as informações detalhadas para execução, pois o responsável pela elaboração já possui conhecimento prévio sobre a aplicação. Isso poderia dificultar a execução se, o executor dos testes não for o mesmo que elaborou.
Essa problemática pode ser resolvida com a utilização da metodologia BDD, pois sua especificação é voltada a comportamento, sendo exemplificados detalhadamente todos os passos para execução do cenário, como mostra a Figura 5.
Figura 5. Especificação de cenário de teste com BDD
Para agilizar a atividade de execução de testes foi utilizada a técnica de automatização, com intuito de reduzir o esforço empenhado nessa etapa, especialmente quando são necessários testes de regressão, vinculando a metodologia BDD com o propósito de criar documentação em uma linguagem natural, simplificando a manutenção e assimilação dos envolvidos.
Para aplicar a metodologia BDD, foi utilizado o framework JBehave e para automatização dos cenários, as ferramentas de teste Selenium e JUnit.
3.1 Aplicação BDD e automatização
A primeira atividade realizada nesse processo de aplicação de BDD com automatização é o levantamento e especificação dos cenários que são agrupados em estórias. Cada estória (.story) é composta por cenários, como se fossem os casos de testes, porém elaboradas de forma exemplificada baseadas em comportamentos do sistema, conforme visto na Figura 5.
Nesse estudo de caso será apresentado um dos cenários especificados para o módulo de triagem de pacientes. A Figura 6 ilustra o arquivo .story que contém o cenário levantado para ser automatizado, juntamente com uma parte do arquivo .java com seu respectivo mapeamento e seus métodos implementados com o framework Selenium, que por sua vez irá automatizar os passos descritos no cenário.
Figura 6. À esquerda: especificação dos cenários, à direita: steps mapeados no JBehave Após a implementação dos métodos dos cenários, foi implementada a classe de configuração. Essa classe possui: quais canditateSteps devem ser executados, o idioma que o .story será interpretado e o formato que será gerado o relatório, como mostra a Figura 7.
Figura 7. Arquivo de configuração do JBehave
Elaborada a classe de configuração, é utilizada a ferramenta JUnit, que permite executar a classe como JUnit Test e gerar os relatórios que o próprio framework do JUnit e do JBehave disponibilizam. No relatório são indicados os métodos que falharam (fail) e os métodos que não tiveram performance (Not performed), porque não foram executados devido falhas.
4. Resultados obtidos
Conforme visto anteriormente, o sistema de soluções hospitalares possui nove módulos com vários fluxos principais e alternativos. Dessa totalidade, dois módulos foram automatizados. O critério de escolha dos módulos para automatizar foi relacionado aos que apresentavam maiores problemas em produção, em função de mudanças que ocorrem constantemente, requerendo testes de regressão.
A aplicação da metodologia BDD junto à técnica de automatização agregou os seguintes benefícios ao processo de testes: facilidade de elaboração e entendimento dos cenários de testes por todo o time, e redução de esforço com a execução de testes.
Na fase de elaboração dos casos de testes, estórias foram especificadas, contendo um conjunto de cenários em uma linguagem natural, sem termos técnicos e exemplificadas, onde os envolvidos conseguiam contribuir e assimilar o que estava sendo desenvolvido, sem ambiguidade e melhorando a comunicação.
Os testes de regressão, que antes eram custosos e executados manualmente, passaram a ser executados de forma automática. Inicialmente, a automatização é mais custosa que a execução manual, entretanto ganha-se benefícios ao longo das suas execuções, obtendo ganho considerável na agilidade dessa atividade. Com a junção da técnica de automatização e a metodologia de BDD, é possível ter um alto índice de reaproveitamento na implementação dos cenários, facilitando a manutenção nos scripts gerados.
O quadro abaixo faz um comparativo entre um cenário de processo de desenvolvimento tradicional versus orientado a comportamento.
Quadro 1. Comparativo entre o processo Tradicional e com aplicação de BDD Processo de Desenvolvimento
Tradicional
Processo de Desenvolvimento Orientado a Comportamento
Esforço = Elaboração de caso de teste + execução de testes
Esforço = Levantamento de cenários + desenvolvimento das estórias
Durante a execução dos testes, alguns requisitos podem ter sido esquecidos
Maior facilidade por todos para visualizar o que está sendo desenvolvido
Alteração de requisito = problemas na reutilização
Alteração de requisito = facilidade trazida pelo
framework (dicionário de passos)
Baixa automatização de testes, dificuldade para testes de regressão
Alta automatização de testes, facilidade para execução de testes de regressão (aumento na qualidade)
Dificuldade de manutenibilidade de casos de teste
Facilidade na manutenção dos cenários e scripts de teste
Linguagem propensa à ambiguidade Linguagem ubíqua
5. Conclusão
É notável que as organizações valorizam a garantia da qualidade de software, isso justifica a disposição em implantar em seu processo de teste a técnica de automatização, visando à agilidade na execução do processo. Com uso de ferramentas e metodologias, é possível otimizar esforço e tempo, além de aproximar os testes automatizados à
documentação do sistema, utilizando uma linguagem única e fluente entre todos os envolvidos no projeto, inclusive o cliente.
Com o uso de Behavior Driven Development (BDD), é possível notar um ganho significativo na reutilização de código para a implementação de novos testes automatizados, além do auxílio na manutenção contínua e produtiva do código e dos requisitos, onde os testes tornam-se a documentação do sistema escrita em uma linguagem comum sendo documentados naturalmente, atrelando requisito ao código ou seja, o código é gerado a partir de uma descrição textual.
É importante ter o conhecimento de boas práticas e padronizações estabelecidas, favorecendo a escrita e manutenção de testes automatizados de qualidade. Para alcançar êxito nesse processo, é necessário ter cuidado ao adotá-lo, sempre focando em: construir sistemas de qualidade de forma ágil, que atendam as necessidades do cliente, devendo não só fazer corretamente o que o foi solicitado, mas também fazê-lo com segurança e eficiência.
Referências
Astels, D. (2006). “A new look at test-driven development.” Disponível em: <http://blog.daveastels.com/files/BDD_Intro.pdf > Acessado em 12.03.2013.
Bernardo, P., C. (2011) “Padrões de testes automatizados.” Dissertação Universidade de São Paulo apud Schwaber, K., e Beedle M. (2001) “Agile Software Development
with SCRUM”, New Jersey, Prentice Hall. Disponível em:
<http://www.teses.usp.br/.../TestesAutomatizados_PauloCheque> Acessado em: 03.03.13.
Gonçalves, H., N. (2011) “Geração de Testes Automatizados Utilizando Selenium”, Trabalho de Conclusão de Universidade de Pernambuco. Escola Politécnica de Pernambuco. Disponível em: <tcc.ecomp.poli.br/20111/monografia_Hiroshi.doc> Acessado em: 07.03.13.
Hunt, A., Thomas, D. (2003) “Pragmatic Unit Testing in Java with JUnit.” The
Pragmatic Programmers v.2. Disponível em: <
http://books.google.com.br/books/about/The_Pragmatic_Programmer.html?id=5wB QEp6ruIAC&redir_esc=y> Acessado em 25.02.2013.
Inthurn, C. (2001) “Qualidade & teste de Software.” Visual Books, Florianópolis. Maldonado, J., C., Delamaro, M., E., e Jino, M. (2007) “Introdução ao Teste de
Software.” Editora: Elsevier, Campus.
Molinari, L. (2010) “Inovação e Automação de Testes de Software” 1ª Edição. São Paulo-SP.
Santos, R., L. (2010) “Emprego de Test Driven Development no desenvolvimento de aplicações.” Monografia – Universidade de Brasília 2010. Disponível em: <monografias.cic.unb.br/dspace/bitstream/123456789/258/1/monografia.pdf>
Acessado em: 03.03.13.Sommerville, I. (2003) “Engenharia de Software.” 6ª Edição. São Paulo – SP.
