Teste de Regressão

Este artigo descreve de maneira prática como é possível usar um ambiente automático para teste de software integrando as ferramentas Open Source conhecidas para tornar o processo de teste ágil e sem custos adicionais para o projeto.

Este artigo discute o uso de ferramentas open source de teste automático para gerenciamento de casos de teste, cadastro de defeitos e automação de casos de teste usando a plataforma WEB e Java para realizar a integração e comunicação entre elas com o objetivo de agilizar as atividades de teste de regressão dentro de um projeto de software que utiliza a metodologia Scrum de desenvolvimento.

O que é Teste de regressão?

O teste de regressão é uma técnica do teste de software que consiste na aplicação de versões mais recente do software, para garantir que não surgiram novos defeitos em componentes já analisados. Se, ao juntar o novo componente ou as suas alterações com os componentes restantes do sistema surgirem novos defeitos em componentes inalterados, então considera-se que o sistema regrediu.

Muitas vezes são usadas ferramentas específicas para o teste de regressão, chamadas de ferramentas de automação. Elas conseguem um resultado mais exato do teste executando exatamente os passos seguidos para o teste das primeiras versões já que elas permitem a gravação do teste. Wikipédia

Atualmente, cada vez mais empresas buscam a diminuição dos custos nas atividades de produção e mais agilidade na fase de teste para trazer o produto para o mercado de maneira rápida e com qualidade . Nesse cenário, as metodologias ágeis de desenvolvimento ganham evidência, pois se destacam dos processos de desenvolvimento tradicionais devido, principalmente, ao fato de darem prioridade ao desenvolvimento de funcionalidades através de código executável ao invés da produção de extensa documentação, e ainda, respostas rápidas às mudanças e colaboração com o cliente ao invés de seguir planos rígidos e negociações contratuais.

O que é Teste de Software?

Teste de software é o processo de execução de um produto para determinar se ele atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado. O seu objetivo é revelar falhas em um produto, para que as causas dessas falhas sejam identificadas e possam ser corrigidas pela equipe de desenvolvimento antes da entrega final. Por conta dessa característica das atividades de teste, dizemos que sua natureza é “destrutiva”, e não “construtiva”, pois visa ao aumento da confiança de um produto através da exposição de seus problemas, porém antes de sua entrega ao usuário final.

O conceito de teste de software pode ser compreendido através de uma visão intuitiva ou mesmo de uma maneira formal. Existem atualmente várias definições para esse conceito. De uma forma simples, testar um software significa verificar através de uma execução controlada se o seu comportamento corre de acordo com o especificado. O objetivo principal desta tarefa é revelar o número máximo de falhas dispondo do mínimo de esforço, ou seja, mostrar aos que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos.

Em metodologias ágeis o desenvolvimento é iterativo, com isso o processo de teste deve seguir essas iterações e deve ser executado eficientemente de maneira rápida e para isso utiliza ferramentas para a automação de testes.

O desafio das equipes de teste com esse cenário é justamente adaptar todos os procedimentos necessários para realizar teste de software em um ambiente ágil onde nem sempre o software é bem especificado em documentos e o tempo e os recursos para realizar as atividades de teste não são suficientes.

Nesse contexto, esse artigo irá compartilhar a experiência de adaptar o processo de teste de software, tornando-o ágil usando para isso a integração das ferramentas de automação de teste de software Open Source conhecidas pela comunidade de testadores: TestLink, Selenium e Mantis.

A ferramenta Testlink, Figura 1, é Open Source feita em php e é usada por equipes de teste para gerenciar os planos de teste, escrever casos de teste, organizá-los em suites, cadastrar resultados das execuções e gerar relatórios. Ela atua como um editor e organizador de casos de teste, salvando todas as informações relacionadas na sua base de dados, além de facilitar a geração de documentação de plano de teste, relatórios e controle das versões de execução de teste.

A ferramenta Selenium RC e IDE é uma ferramenta para automação de testes funcionais caixa-preta que utiliza a abordagem rec-and-play e oferece suporte a testes em aplicações web. O Selenium IDE é um plugin do Mozilla Firefox, com ele é possível gravar ações do usuário no browser criando scripts de teste para edição e execução posteriormente. As gravações se tornam scripts de testes em diversas linguagens como: Java, Ruby, C#, Pearl, PHP, HTML e Python. Pode ser executado em vários navegadores, entre eles: Firefox, IE e Chrome.

O Mantis (ver Figura 2) é uma ferramenta OpenSource para registro e controle de defeitos. Ele possui uma interface amigável onde o testador registra os defeitos, o desenvolvedor recebe a notificação por e-mail e atualiza a situação do defeito que poderá ser: confirmed (defeito confirmado), acknowledge (sob investigação), feedback (precisa de esclarecimento) e Resolved (defeito resolvido). O testador ao receber a mudança de situação do defeito poderá responder reabrindo o defeito ou validando e fechando o defeito. Pela ferramenta é possível visualizar a lista de defeitos e exportar para os formatos excel e word.

Como principal foco deste artigo, serão mostrados o processo de teste usado para a metodologia ágil scrum, tutorial de como a integração das ferramentas são feitas e os resultados da experiência no uso de integração de ferramentas de automação de testes funcionais em um ambiente de desenvolvimento conduzido pelo SCRUM. No decorrer do artigo mostraremos as notáveis vantagens e os problemas de se adotar tal prática de qualidade no dia-a-dia de trabalho.

Scrum

Em 1999, Ken Schwaber e Mike Beedle escreveram o primeiro livro sobre Scrum: Agile Software Development with Scrum. Os autores definem Scrum não como uma metodologia, mas como um framework conceitual, um conjunto de ideias, técnicas e práticas que levam ao estabelecimento de uma atitude mental de trabalho. As equipes Scrum são formadas como times, e devem assumir um comprometimento com o trabalho que alcança níveis bem superiores aos encontrados em grupos de trabalho convencionais. Embora as origens de Scrum remontem, portanto, às décadas de oitenta e noventa, sua popularização entre desenvolvedores de sistemas se deu a partir da divulgação, em 2001, do “Manifesto para o Desenvolvimento Ágil de Software”, mais comumente referido como “Manifesto Ágil”.

Os fundamentos cultivados por Scrum baseiam-se em trabalhos muito anteriores, de Ikujiro Nonaka e Hirota Takeuchi, da Toyota, que em 1986 publicaram um artigo onde propunham um estilo de gestão holístico (considera que o todo é maior que a soma das partes), onde a equipe busca, como em um jogo de futebol, de forma integrada, chegar ao gol.

Visão geral do projeto a ser testado

A plataforma de desenvolvimento do projeto onde foi aplicada essa experiência é Web, a linguagem utilizada é PHP, o banco de dados é MySQL. O sistema conta com 9 telas, onde 4 são formulários de cadastro e 4 são consultas e relatórios. A metodologia de desenvolvimento usada para esse projeto foi Scrum (ver Figura 3).

Scrum é uma metodologia extremamente ágil e flexível, centrada na equipe, utilizada para o desenvolvimento in­cremental e iterativo de qualquer produto, no caso do nosso artigo, desenvolvimento de software. Como princípios Scrum destacam-se:

• as funcionalidades do sistema (estórias) listadas e priorizadas pelo cliente (Product Owner) chamada de Product Backlog;

• Iterações chamadas de Sprint em que as atividades são desenvolvidas em um tempo limitado (2 ou 4 semanas) que inclui dentre outras tarefas a análise, design, codificação e teste;

• Antes de cada Sprint a equipe realiza uma reunião chamada de Sprint Planning onde as funcionalidades e as tarefas a serem feitas são definidas. Todos os dias a equipe se reuni durante no máximo quinze minutos para informar suas atividades e os impedimentos (Daily Meeting). O responsável da equipe pela manutenção desse processo, reuniões e resolução de impedimentos é o Scrum Master.

Processo de Teste

Como no Scrum o desenvolvimento e o teste precisam ser ágeis, a equipe de teste do Projeto era composta por um líder de teste e dois testadores sendo um dedicado a automação dos testes no Selenium. A equipe decidiu automatizar os casos de teste sabendo que isso minimizaria custos, aumentaria a produtividade e garantiria sua qualidade, reduzindo prin­cipalmente, o tempo de teste. Além disso, a automação iria ajudar a cobrir as funcionalidades verificadas adequadamente.

As estórias de usuário eram feitas com o Product Owner (PO) e detalhadas em cenários para a melhor compreensão da funcionalidade. Através das estórias e dos cenários os casos de testes eram escritos. Houve a uti­lização de uma prática chamada Desenvolvimento Dirigido por Testes de Estórias (Story-Test Driven Development). Esta prática diz que antes de começar a desenvolver a estória, a equipe de programadores, analistas, gerentes, testadores e clientes devem colaborar para definir os critérios de aceitação e cenários. Critérios esses que foram utilizados pela equipe de teste como base para que a qualidade nos testes e nas funcionalidades testadas fosse alcançada. Abaixo nós temos um exemplo de cenário definido no contexto do projeto:

Dado: O usuário está na sua lista de tarefas.

E: O usuário preenche o campo de tarefa com “Minha tarefa”

Então: Ele clica em Adicionar.

Então: O usuário deve ver "Minha nova tarefa" na lista de tarefas.

O ciclo de teste era executado de maneira Iterativa como o Sprint e se baseava nas seguintes práticas:

1) Criar e Atualizar os casos de teste baseados nas estórias e cenários escritos no (Product Backlog) apenas para as funcionalidades selecionadas no Sprint utilizando a ferramenta TestLink;

2) Criar e Atualizar os scripts de testes automáticos na ferramenta de automação Selenium a partir dos casos de teste especificados.

3) Executar os testes automáticos e paralelamente executar testes manuais exploratórios;

4) Os defeitos encontrados eram registrados no Mantis, os desenvolvedores recebiam um e-mail com as informações dos defeitos cadastrados;

5) O relatório dos defeitos era gerado, os desenvolvedores recebiam, analisavam e trabalhavam na solução de acordo com a sua criticidade;

6) Quando os defeitos eram resolvidos, os desenvolvedores liberavam uma nova versão do sistema para os defeitos corrigidos serem validados;

7) Os testadores validavam os defeitos na nova versão e executavam todos os testes automáticos como regressão, para garantir que outra parte do sistema não foi afetada pelas alterações no código.

O relatório sumarizado com todos os defeitos encontrados era gerado e enviado para a equipe. Este processo está representado na Figura 4. Contudo, conforme a suite de teste crescia com a adição de mais teste, chegando até a 210 casos de teste, executá-los na regressão ficava cada vez mais trabalhoso e algumas pendências de execução acabavam para serem terminadas no próximo Sprint, o que queria dizer débito técnico para a equipe de teste.

Integração das ferramentas de teste

Com o objetivo de não deixar débito técnico das atividades de teste de regressão para os próximos sprints, a automação com as ferramentas precisou ser otimizada e para isso realizamos a integração TestLink com Mantis e Testlink com Selenium. Com a integração entre as ferramentas pode-se ter a rastreabilidade entre caso de teste e defeito e caso de teste e script de teste automático.

Conceitos de teste

A atividade de teste é composta por alguns elementos essenciais que auxiliam na formalização desta atividade. Esses elementos são os seguintes:

• Caso de Teste. descreve uma condição particular a ser testada e é composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado.
• Procedimento de Teste. é uma descrição dos passos necessários para executar um caso (ou um grupo de casos) de teste.
• Critério de Teste: serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto.

Integração Mantis e Testlink

A integração do Testlink com o mantis ou qualquer outro bugtracker é feita através de tabelas do banco de dados. Isto por que o Testlink não está disponível para enviar dados para o bugtracker e nem receber dados do bugtracker.

Com a configuração para a integração feita, o processo sob o ponto de vista do usuário ocorre desta maneira:

1. Durante a execução de um teste, ele falha;
2. O Usuário salva resultado da execução no testlink;
3. O Usuário registra esse defeito na ferramenta de bugtracker;
4. No Testlink, na tabela que exibe os dados dos resultados de execução, um ícone para acessar recurso do bugtracker estará disponível;
5. O Usuário clica no link que abre uma página da Web usada para a comunicação com o bugtracker em questão;
6. O Usuário insere o ID do defeito registrado;
7. Depois que o usuário salva a execução, o Testlink irá mostrar os dados retirados do banco de dados do bugtracker.

Para configurar o Testlink com o mantis, é necessário que a versão do Testlink instalado seja igual ou maior que 1.7.0 e o Mantis deve estar instalado no mesmo webserver.

O primeiro passo para configurar o Mantis para essa integração é habilitá-lo para receber login anônimo. Para isso, basta abrir o seu arquivo de configuração config_inc.php e alterá-lo desta forma mostrada abaixo:

# --- anonymous login -----------

# Allow anonymous login

$g_allow_anonymous_login = ON;

$g_anonymous_account = "dummy";

Para configurar o Testlink, é necessário ir no diretório e editar o arquivo /CFG/mantis..cfg.php, como é mostrado abaixo:

/** The DB host to use when connecting to the mantis db */

define("BUG_TRACK_DB_HOST", "calypso");

/** The name of the database that contains the mantis tables */

define("BUG_TRACK_DB_NAME", "mantis_bt");

/** The DB type being used by mantis */

define("BUG_TRACK_DB_USER", "mantis_bt_user");

/** The DB password to use for connecting to the mantis db */

define("BUG_TRACK_DB_PASS", "mantis_bt_password");

/** link to the bugtracking system, for viewing bugs */

define("BUG_TRACK_href", "http://calypso/mantis/view.php?id=");

/** link to the bugtracking system, for entering new bugs */

define("BUG_TRACK_ENTER_BUG_href","http://calypso/mantis/");

A integração será habilitada copiando as linhas do arquivo config.inc.php para custom_config.inc.php da maneira como está abaixo:

$g_interface_bugs="MANTIS";

Ao iniciar o Testlink e indo para a página de execução, o link para inserir o defeito registrado no Mantis estará aparecendo como indica a Figura 5.

Essa integração permite para a equipe de teste identificar e rastrear quais defeitos foram gerados durante a execução dos casos de teste. Isto fornece métricas para a equipe de teste identificar quais casos de teste encontraram mais defeitos e os defeitos não associados a casos de teste podem alimentar a suite de teste com novos cenários a serem validados.

Integração Testlink e Selenium

Com essa integração é possível executar os testes automáticos no Selenium e retornar os resultados da execução no Testlink facilitando assim o registro dos testes de regressão em uma suite de testes muito grande. É recomendável fazer essa integração nas funcionalidades do sistema que estão estáveis, que não irão ser modificadas durante o projeto, pois assim os testes automáticos retornarão resultados corretos.

A partir da versão 1.8.5 já é possível integrar o Testlink com o Selenium através de uma api: testlink-api-client. Para o projeto usamos a automação no ambiente java: Eclipse IDE, jdk-1.6.0-17 e bibliotecas do Selenium RC 1.0.3.

Primeiramente, para configurar o Testlink é necessário habilitar o projeto de teste para a automação. Isso é feito marcando o campo: Enable Test Automation na página do projeto de teste no Testlink (Figura 6).

Na pasta do testlink é necessário alterar o arquivo custom_config.inc.php. As duas variáveis que precisam ser alteradas são:

  $tlCfg->api->enabled
  $tlCfg->exec_cfg->enable_test_automation 

As duas linhas devem ser copiadas e coladas no arquivo custom_config.inc.php com os seguintes valores:

  $tlCfg->api->enabled = TRUE;
  $tlCfg->exec_cfg->enable_test_automation = ENABLED 

Para a integração acontecer uma chave de acesso ao Testlink deve ser gerada. Isso é feito indo na página de Settings na seção API Interface clicando no botão Generate a new Key (Figura 7). Essa chave é criada por usuário e permitirá ao Testlink identificar quem está tentando acessar os serviços XML-RPC.

Com isso, é a vez de preparar o ambiente de desenvolvimento no projeto de teste automático do Selenium. Primeiramente, adiciona-se no projeto as seguintes bibliotecas:

• testlink-api-client-2.0.jar;
• todas as libs, exceto a junit, da pasta lib.

No ambiente do Selenium no eclipse deve-se criar uma classe de interface com as informações referentes ao servidor e a aplicação testada. No projeto chamamos a classe de Itestlink (Listagem 1). Ela possui as seguintes variáveis:

• DEVKEY: chave de acesso ao Testlink;
• URL: endereço do Testlink para acesso ao xmlrpc.php (.../testlink/lib/api/xmlrpc.php);
• testProject: nome do projeto de teste no Testlink;
• testPlan: nome do plano de teste no Testlink;
• testCase: nome do caso de teste no Testlink;
• buildName: nome da build no Testlink.

Listagem 1. Código da Interface para Testlink

  package selenium.integracao;
   
  public interface ITestlink {
       final String DEVKEY = ""; //chave de acesso ao testlink  
       final String URL = "http://.../testlink/lib/api/xmlrpc.php";  
            final String testProject = "Test Project";  
            final String testPlan = "Test Plan";  
            final String buildName = "Build 1";  
            final String testCase = "Test 1";  
  } 

Seu caso de teste deve importar as classes testlink.api.java.client.TestLinkAPIClient e testlink.api.java.client.TestLinkAPIException, estender a classe do Selenium TestCase e implementar essa interface Itestlink, como podemos perceber na Listagem 2.

Listagem 2. Código de Script de Teste

  public class TestCaseSelenium extends TestCase implements ITestlink {  
         
       Selenium selenium;  
       SeleniumServer server;  
         
       String serverHost = "localhost";  
       int serverPort = 4444;  
       String browserStartCommand = "*firefox";  
       String browserURL = "http://...testlink/login.php?note=expired/";  
         
       public void setUp() throws Exception {  
          selenium = new DefaultSelenium(serverHost, serverPort, browserStartCommand, browserURL);  
          selenium.start();  
       }  
         
       @Test  
       public void testTestlinkLogin() throws Exception {  
          String result = null;  
          String note = null;  
            
          try {  
           selenium.open("/");  
                selenium.open("/login.php");
           selenium.click("name=login_submit");
           selenium.waitForPageToLoad("30000");
           assertTrue(selenium.isTextPresent("Try again! Wrong login name or password!")); 
            
          result = TestLinkAPIResults.TEST_PASSED;  
            
          } catch (Exception e) {  
             result = TestLinkAPIResults.TEST_FAILED;  
             note = e.getMessage();  
             e.printStackTrace();  
          } finally {  
             ResultadoExecucao.reportTestCaseResult(PROJETO, PLANO, CASO_TESTE1, BUILD, nota, resultado);
  TestLinkAPIClient testlinkAPIClient = new TestLinkAPIClient(DEVKEY, URL);  
            testlinkAPIClient.reportTestCaseResult(testProject, testPlan, testCase, buildName, note, result);  
                   
          }  
       }  
         
       public void tearDown() throws Exception {  
          selenium.stop();  
       }  
    } 

Para executar no eclipse basta clicar em cima da classe de teste com o botão direito do mouse e selecionar Run->Junit Test. O resultado será automaticamente cadastrado no Testlink.

Com isso, é possível economizar tempo em execução facilitando a geração de relatório de teste.

Pontos positivos

A automação integrada trouxe benefícios para a equipe de teste e para a qualidade do projeto alcançando a meta de obter um processo de teste efetivo e com mais agilidade.

Quanto à equipe foi observado que:

• Aumentou a segurança da equipe quanto ao teste automático, já que foram feitos testes mais elaborados e complexos no Selenium;
• Não houve sobrecarga de execução de casos de teste, pois grande parte estava automatizada e integrada;
• O ciclo de teste mostrado na Figura 4 era completamente executado sem deixar débito técnico para o próximo sprint, levando em consideração a execução da etapa dos testes de regressão e dos testes das novas funcionalidades;
• Os testes de regressão foram responsáveis por identificar a grande parte dos defeitos encontrados no projeto, identificando quais funcionalidades eram afetadas pelas alterações de código;
• Métricas para melhoria da suíte de testes puderam ser geradas como, por exemplo, a identificação de casos de teste que não estavam associados ao Mantis;
• Foi possível a montagem de uma Suíte de Testes onde todos os scripts automáticos eram executados sequencialmente. Isto economizou muito tempo;
• A automação economizava tempo. então testes manuais exploratórios contribuíram para que defeitos de funcionalidades, performance e usabilidade fos­sem encontrados;
• Por ser uma aplicação WEB, era satisfatório que o Sistema executasse perfeitamente em pelo menos dois navegadores. Os mais utilizados pelos clientes eram o Internet Explorer 8 e o Mozilla Firefox. Testes de regressão encontraram inúmeros erros de cross-browser. Estes eram identificados rapidamente.

Dificuldades

Durante a adequação do processo de teste, dificuldades também foram observadas pela equipe dentre as quais podemos citar:

• A metodologia Scrum possibilita a mudança de requisitos no meio do processo de desenvolvimento. Assim, houve scripts automáticos que foram totalmente perdidos por terem ficado obsoletos após a mudança de algum requisito do sistema;
• A aplicação Web em desenvolvimento apresentou instabilidades e mudanças no framework, então a cada mudança das propriedades de algum componente o script que testava a página se tornava inválido, pois na abordagem rec-and-play o Selenium recupera o nome e propriedades do objeto seleciona­do para gravar o script. Se o componente mudou, naturalmente o script automático não serve mais;
• Quando a interface do sistema não está estabilizada e passa por mudanças de componentes, muito tempo se leva na atualização dos scripts de teste automáticos consumindo mais recursos de tempo e pessoas, o que nos levou a conclusão de que apenas integraríamos os casos de teste de funcionalidades estáveis que não passariam mais por mudanças em sua interface.

Conclusão

As metodologias ágeis de desenvolvimento trouxeram não só mudanças de paradigma para os desenvolvedores de software. Os testadores também tiveram que se adaptar às mudanças, pois as atividades de teste passaram a buscar meios de não só gerar documentos de execução de testes como também torná-los artefatos dinâmicos que respondam às solicitações de mudança no decorrer do projeto.

A automação vista como ferramenta-chave para a agilidade do processo de teste realmente trará benefícios no projeto, porém é necessário que a equipe de teste saiba extamente como, quando e em que ponto de maturidade do time e do desenvolvimento do sistema essa ferramenta deverá ser usada.

Apesar das dificuldades encontradas em ajustar atividades de configuração, desenvolvimento e programação de scripts de teste, os resultados positivos agregam valor pois as ferramentas Open Source não gastam recursos financeiros do projeto, apenas demandam tempo de aprendizagem que vale a pena investir.

Saiba mais sobre Testes de Software ;)

• Guia de Testes de Software:
  Neste guia completo você encontrará diversos artigos e vídeos que podem ser usados ao longo dos seus estudos sobre Testes de Software, abordando diversas técnica e ferramentas. 80

Revista Engenharia de Software Magazine 43 ;)

• :
  Nesta edição da revista Engenharia de Software você confere a Produtividade de Times Ágeis.