10/4/2014 DevMedia - Versão para impressão

DevMedia - Versão para impressão

Teste de regressão ágil com

integração de ferramentas open
source de teste
De que se trata o artigo
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.

Em que situação o tema é útil

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.
Resumo Devman
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.

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 (ler Nota DevMan 1). 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.

Nota Devman 1: 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
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 1/13
10/4/2014 DevMedia - Versão para impressão

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.

[abrir im age m e m jane la]

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 2/13
10/4/2014 DevMedia - Versão para impressão
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.

[abrir im age m e m jane la]

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 (ler Nota DevMan 2).
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.

Nota Devman 2: 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

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 3/13
10/4/2014 DevMedia - Versão para impressão

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

[abrir im age m e m jane la]

Figura 3. Processo Scrum

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 4/13
10/4/2014 DevMedia - Versão para impressão

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

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 5/13
10/4/2014 DevMedia - Versão para impressão

para serem terminadas no próximo Sprint, o que queria dizer débito técnico para a equipe de
teste.

[abrir im age m e m jane la]

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 (ler Nota DevMan 3).

Nota Devman 3: 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

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 6/13
10/4/2014 DevMedia - Versão para impressão

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:

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 7/13
10/4/2014 DevMedia - Versão para impressão

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

[abrir im age m e m jane la]

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

[abrir im age m e m jane la]

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 8/13
10/4/2014 DevMedia - Versão para impressão

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.

[abrir im age m e m jane la]

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;
http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 9/13
10/4/2014 DevMedia - Versão para impressão

• testCase: nome do caso de teste no Testlink;

• buildName: nome da build no Testlink.

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 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";

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;

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 10/13
10/4/2014 DevMedia - Versão para impressão

} 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

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 11/13
10/4/2014 DevMedia - Versão para impressão

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.

LUANA LOBÃO
Atualmente trabalha com VV&T e desenvolvimento em projetos de jogos para mobile, nas
plataformas windows phone, ios e android. Está aprendendo sobre desenvolvimento e teste de caixa
branca na Plataforma Unity 3D. Possui experiência com gerenciamento, controle financeiro e técnico
de Projetos de P&D. Já trabalhou com automação de teste para as plataformas Desktop (Java), Web

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 12/13
10/4/2014 DevMedia - Versão para impressão

(Java, C++), Data Warehouse (Cognos da IBM) e mobile (Symbian, Java ME e Windows Phone).
Possui certificação internacional em teste de software pelo International Software Testing
Qualifications Board (ISTQB / CTFL - Certified Tester Foundation Level) e certificado de Scrum
Developer (CSD) pela Scrum Alliance.

Eliane Collins
Mestranda de Engenharia elétrica pela Universidade Federal do Amazonas, MBA em Gerenciamento
de Projetos e Bacharel em Engenharia de Computação pela Universidade Estadual do Amazonas, 7
anos atuando no desenvolvimento de Software, desses 4 anos em Teste de Software. Trabalha
atualmente no Instituto Nokia de Tecnologia - INdT, como Pesquisadora, onde lidera uma equipe de
teste de software e desenvolve sistemas Web.

http://www.devmedia.com.br/websys.5/webreader_print.asp?cat=48&artigo=4133&revista=impressao_43#a-4133 13/13