Teste de Regress�o: Aprendendo Teste de Software na Pr�tica

Por que eu devo ler este artigo: No cen�rio atual, as empresas buscam a diminuiç�o dos custos em projetos e agilidade na fase de teste para trazer o produto para o mercado r�pido e com qualidade. Com isso, as equipes de teste possuem o desafio de adaptar seus procedimentos de teste �s metodologias �geis, onde a automaç�o de testes � ferramenta fundamental para atingir tal objetivo.

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.

Figura 1. TestLink.

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.

Figura 2. Mantis.

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.

Figura 3. Processo Scrum.

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:

Cenario: Adicionar Tarefa.

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.

Figura 4. Processo de Teste Iterativo.

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:

Durante a execuç�o de um teste, ele falha;
O Usu�rio salva resultado da execuç�o no testlink;
O Usu�rio registra esse defeito na ferramenta de bugtracker;
No Testlink, na tabela que exibe os dados dos resultados de execuç�o, um �cone para acessar recurso do bugtracker estar� dispon�vel;
O Usu�rio clica no link que abre uma p�gina da Web usada para a comunicaç�o com o bugtracker em quest�o;
O Usu�rio insere o ID do defeito registrado;
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.

Figura 5. Testlink integrado com Mantis.

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).

Figura 6. Enable Test Automation.

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.

Figura 7. API Key.

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.

Links

[Bissi (2007)] Bissi, W., Scrum � Metodologia de Desenvolvimento �gil
http://revista.grupointegrado.br/revista/index.php/campodigital/article/view/312/146

[Collins e Lucena 2010] Collins Eliane, Lucena Vicente. 2010. Iterative Software Testing Process for Scrum and Waterfall Projects with Open Source Testing Tools Experience. In Proceedings of the 22nd IFIP International Conference on Testing Software and Systems2010( ICTSS�10). CRIM, 2010. 115-120 p. [ISBN : 978-2-89522-136-4] .

Master [Hu Zhi-gen 2009] Hu Zhi-gen; Yuan Quan; Zhang Xi;,
"Research on Agile Project Management with Scrum Method," Services Science, Management and Engineering, 2009. SSME "09. IITA International Conference on, vol., no., pp.26-29, 11-12 July 2009. DOI: 10.1109/SSME.2009.136

[Korel e Al-Yami 1998] Korel, B. e Al-Yami, A. (1998), Automated Regression Test Generation, Department of Computer Science Illinois Institute of Technology e College of Technology at Dammam, Chicago,
http://portal.acm.org/citation.cfm?id=271771.271803

[Leal 2009] Leal, I. (2009) �Requisitos de Metodologias de Teste de Software para Processos �geis�,
http://homepages.dcc.ufmg.br/~rodolfo/dcc823-1-09/Entrega2Pos/igor2.pdf, Outubro.

[Mancardi 2007] Mancardi, Francisco 2007: How to setup bugtracking system integration Mantis and Bugzilla example
http://www.teamst.org/_tldoc/1.7/tl-bts-howto.pdf

[Mantis 2011]
www.mantisbt.org/

Nogueira Elias, 2010: Integraç�o Selenium e Testlink
http://sembugs.blogspot.com/2010/10/integracao-selenium-e-testlink.html

[Presman (1995)] Presman, R. S. Engenharia de Software. S�o Paulo: Makron Books do Brasil, 1995.

[Selenium 2011]
seleniumhq.org/

[Siebra et al 2010] Siebra, Clauirton A; Lino, Nancy L; Silva, Fabio Q B; Santos, Andre L M;
, "On the specification of a test management solution for evaluation of handsets network operations," Automation Quality and Testing Robotics (AQTR), 2010 IEEE International Conference on , vol.2, no.,pp.1-6, 28-30 May 2010. DOI=10.1109/AQTR.2010.5520833. (2010).

[TestLink 2011]
http://testlink.sourceforge.net/docs/testLink.php

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.