[1] O documento discute como as práticas de Integração Contínua e Testes Automatizados podem melhorar o desenvolvimento de software, tornando-o mais confiável para o usuário final. [2] Ele apresenta uma pesquisa realizada em uma empresa que analisou a implementação dessas técnicas e propôs mudanças no processo de desenvolvimento. [3] Os resultados sugerem que essas práticas podem contribuir para a construção de um software de maior qualidade.

1. Melhoria do desenvolvimento de software utilizando
práticas de Integração Contínua e Testes Automatizados
Alex Warmling1
, Anita Maria da Rocha Fernandes1
1
Curso de pós-graduação em Qualidade e Engenharia de Software – Universidade do
Vale do Itajaí (UNIVALI) – Florianópolis – SC – Brasil
alexw@edu.univali.br, anita.fernandes@univali.br
Abstract. With the growth of web applications increasing each year, new
practices in software development have been emerging. Their goal is always to
facilitate the work of technical team either through new processes or new tools
to assist in operations. This paper aims to show how the use of some
continuous integration and test automation techniques can help the
development team produce software with more confidence and quality, making
it better and more reliable for the end user.
Resumo. Como o crescimento das aplicações web vem aumento a cada ano,
novas práticas no desenvolvimento de software estão surgindo. O objetivo
delas é sempre o de facilitar o trabalho da equipe técnica, seja através de
novos processos ou novas ferramentas para suportar a operação. Este artigo
visa mostrar como a aplicação de algumas técnicas de Integração Contínua e
automação de testes podem auxiliar a equipe de desenvolvimento a produzir
software com mais confiança e qualidade, tornando-o melhor e mais confiável
para o usuário.
1. Introdução
O desenvolvimento de software vem evoluindo a anos e atualmente com a ascensão da
internet no país, as aplicações web estão cada vez maiores, mais complexas e contando
com um número cada vez mais expressivo de usuários. Com o intuito de agilizar o
desenvolvimento e garantir mais qualidade nos produtos de software, empresas vem
investindo em novas práticas/métodos de trabalho, como Integração Contínua (CI –
Continuous Integration), Entrega Contínua (CD – Continuous Delivery) e automação de
testes que antes eram feitos de forma manual, sendo desta maneira mais suscetíveis a
erros. Através destas práticas, hoje é possível automatizar boa parte das tarefas do
desenvolvimento de um software, entre elas o build, o teste e o deploy de uma
aplicação. Isso faz com que o processo e o próprio software tenham menos erros, pois
além de o processo estar automatizado, existem testes automáticos implementados para
todas as camadas do software, como unitários e integração. Com essa prática as
empresas conseguem descobrir possíveis falhas antes que cheguem ao cliente final,
evitando prejuízos financeiros e de imagem.
Porém, essas técnicas demandam também bastante trabalho e investimento por
parte da empresa, pois não podem ser implementadas da noite para o dia. Algumas terão
um custo maior para a empresa, que precisa enxergar a longo prazo o benefício do uso
de cada uma detas técnicas. Outros métodos precisam de concentimento e apoio da

2. equipe para que sejam implantados e funcionem, como as práticas ágeis descritos no XP
(eXtreme Programming) e no SCRUM, por exemplo.
Sendo assim, este estudo tem como objetivo comprovar como o uso de testes de
software automatizados aliados a outras técnicas de integração continua e entrega
contínua podem contribuir para a construção de um software melhor e com mais
qualidade, em uma equipe que já utiliza algumas práticas do XP e do SCRUM no seu
processo de desenvolvimento.
2. Metodologia
Inicialmente realizou-se o levantamento do processo atual de desenvolvimento de
software da empresa alvo. Este levantamento foi realizado através de pesquisa
documental, entrevista não estrutura com os colaboradores e também através da
observação direta das atividades que eram realizadas. Para mapear o fluxo destas
atividades utilizou-se a ferramenta Bizagi.
Após o mapeamento das atividades foi realizado então um estudo bibliográfico
sobre práticas ágeis, focando nos aspectos da integração contínua, entrega contínua e
automação de testes. Estas práticas prevêem várias atividades e aspectos que devem ser
observados e obedecidos pelo time no seu processo de desenvolvimento de software,
como por exemplo, manter um sistema de controle de versão, seja ele centralizado ou
distribuído, onde todo o time deve se preocupar com a qualidade do que está sendo
desenvolvido e principalmente que se tenha sempre uma versão funcional do sistema ao
final do dia.
Ao final deste estudo bibliográfico e das observações realizadas, foram
propostas algumas mudanças no processo de desenvolvimento, para que fosse possível
analisar se houveram ou não melhorias em relação ao que estava sendo utilizado
anteriormente.
2.1 Sobre a empresa alvo
O trabalho de análise do processo de desenvolvimento de software foi realizado em uma
empresa privada de Florianópolis, que a 6 anos se dedica à pesquisa, desenvolvimento e
inovação em soluções de personalização voltadas para o comércio eletrônico tanto
nacional quanto internacional.
A empresa possiu alguns produtos que são construídos de forma separada, onde
cada produto tem um time específico responsável, porém compartilham uma mesma
base de dados. Como cada produto tem um time responsável, as técnicas de
gerenciamento e de desenvolvimento dos produtos podem ser distintas, uma vez que
estes times tem autonomia para decidir a forma de trabalho, mais buscasndo sempre que
algumas práticas estejam alinhadas em todos os times. Alguns destes times já utilizam
as técnicas e práticas de integração contínua, outros ainda estão iniciando timidamente e
é neste grupo que este artigo tomará foco.
O processo de desenvolvimento do time alvo inicia com o levantamento de
requisitos pelo analista de negócio da empresa. Como geralmente os projetos são
parecidos, poucas novidades surgem entre um projeto e outro, desta maneira o processo
é bastante simples. Porém, isto tem gerado alguns problemas durando o

3. desenvolvimento, pois não se tem uma ordem exata para a sequencia de cada tarefa
dentro de um time técnico. Após o levantamento dos requisitos adicionais, o
desenvolvedor valida-os e então começa a codificar. Quando a codificação do requisito
está pronta, ele gera um build e disponibiliza para a equipe de testes executar os casos
de testes. Estes testes são na grande maioria manuais, onerando muito o tempo do
testador.
Após os testes, possíveis erros são reportados para o desenvolvedor realizar as
devidas correções ou caso não tenha nenhum ocorrência de erros o pacote pode ser
liberado para publicação. Então em seguida, o desenvolvedor publica este pacote em
produção, para que os testes de layout sejam feitos no ambiente real do cliente, porém
sem ainda habilitar a aplicação. Com os testes de layout realizados e se tudo estiver
correto, o analista de negócios comunica o cliente da publicação e solicita a aprovação
para habilitar a aplicação.
A Figura 1 apresenta o processo citado acima.
Figura 1. Processo de desenvolvimento objeto do estudo
3. Revisão bibliográfica
Neste capítulo, serão vistos alguns conceitos necessários para a compreensão das
práticas que foram abordadas como proposta deste artigo. Primeiramente, fala-se um
pouco sobre metologias ágeis, abordando aspectos do manifesto ágil. Em seguida, tem-
se uma breve descrição sobre os conceitos de integração contínua e entrega contínua,
mostrando alguns aspectos positivos da adoção destas práticas no dia a dia de trabalho.
Para finalizar são então apresentados alguns aspectos sobre a automação de testes e um
breve resumo sobre as ferramentas utilizadas para realização das melhorias.
3.1 Práticas ágeis
Os métodos ágeis nasceram na décade de 90, sendo que os mais conhecidos atualmente
são o XP e o SCRUM. O intuito destes métodos/práticas é produzir software com mais
qualidade, com menos tempo de desenvolvimento e de forma mais econômica. A
utilização destes métodos muitas vezes é expressa de forma equivocada, pois leva as

4. pessoas a pensarem que o Agile development 1
é sinônimo de agilidade, mas não, é
apenas uma outra metodologia que prevê outros tipos de práticas e que se bem aplicadas
podem resultar em um projeto mais rápido [Wells 2009].
O Manifesto Ágil publicado em 2001 é o Marco da grande disseminação destes
métodos por todo o mundo, onde descreve a essência de um conjunto de abordagens
para melhorar o desenvolvimento de software. O Manifesto Ágil (2001) está baseado em
4 princípios que passam a valorizar:
 Indivíduos e interações mais que processos e ferramentas;
 Software em funcionamento mais que documentação abrangente;
 Colaboração com o cliente mais que negociação de contratos; e
 Responder a mudanças mais que seguir um plano.
3.2 Integração Contínua
Uma das práticas que os métodos ágeis mencionam é a Integração Contínua. Segundo
Fowler (2006), a integração contínua é uma prática de desenvolimento de software,
onde os membros de uma mesma equipe integram seu trabalho com frequênca. Com
isto, ainda segundo Fowler (2006), fica mais fácil e rápido descobrir erros nas
aplicações, pois os builds e os testes são automatizados, permitindo que a correção dos
problemas ocorra mais rapidamente e se entregue um software de melhor qualidade.
Para Humble e Farley (2010), o objetivo da integração continua é deixar o
software sempre em um estado funcional. Afirmando ainda que a Integração Contínua
inclui uma mudança grande de paradigma, dizendo que:
“Sem integração contínua, o seu software
está quebrado até que alguém prove que ele
funciona, geralmente durante a fase de
testes ou de integração. Com a integração
contínua, o seu software está
comprovadamente funcionando e você sabe
quando ele quebra podendo corrígi-lo
imediatamente.”
3.3 Entrega Contínua
Para que a Integração Contínua faça sentido, a prática de Entrega Contínua também
deve ser adotada. Fowler (2013) define Entrega Contínua como sendo uma disciplina de
desenvolvimento de software onde o mesmo é construído de tal forma que pode ser
entregue a qualquer momento.
Segundo Fowler (2013), os principais benefícios desta prática são:
 Menor risco de implantação: uma vez que você faz entregas menores e rodou os
testes automáticos, há menos coisas com chance de conter algo errado;
1
É uma alternativa para a gestão de projetos tradicional, dando ênfase em capacitar pessoas a colaborar e
tomar decisões em equipe, além de planejamento, testes e integração contínuas.

5.  Progresso crível: onde é preferível se ter o pacote em produção do que apenas
acreditar que o desenvolvedor o fez pois marcou a tarefa como completa; e
 Feedback2
do usuário: pois como as entregas são menores e mais rápidas você
descobre antes se o caminho que está tomando está alinhado com as expectativas
do usuário final.
3.4 Testes automatizados
Rouse (2014) define que teste de software automatizado é um processo em que
ferramentas de software executam testes, através de um roteiro, sobre uma outra
aplicação de software, verificando seus requisitos antes que esta seja liberada para
produção. Rouse (2014) diz ainda que o objetivo do teste automatizado é simplificar ao
máximo o trabalho da equipe de qualidade, sintetizando o maior número de testes no
menor número de scripts possível.
Para Dustin et al (1999), estes testes equivalem a um esforço de
desenvolvimento que deve envolver sempre uma estratégia e planejamento de metas,
definição de requisitos, análise, projeto, desenvolvimento, execução e avaliação.
Segundo Crispin e Gregory (2009), existem diversas razões para automatizarmos
os testes, que são:
 Testes manuais são geralmente lentos;
 Os processos manuais são propensos a erros;
 Automação deixa as pessoas com mais tempo para fazer o seu melhor trabalho;
 Fornecem maior segurança para que sejam realizadas quaisquer alterações no
software;
 Fornecem feedback muito mais cedo e com mais frequência;
 Testes são a documentação viva do software; e
 Geralmente a automação oferece um bom retorno sobre o investimento feito.
Mas para que possamos implementar estas práticas com sucesso, alguns outros
softwares de apoio devem ser utilizados neste processo. Ferramentas que possam apoiar
a automação dos builds de integração, outras para que o código-fonte seja compartilhado
com toda a equipe, outras para que se possa automatizar os testes, dentre outras
ferramentas de gestão que apoiam as práticas ágeis.
3.5 Controle de versão
Sistemas de controle de versão, conhecidos também como sistemas de gerenciamento de
cóodigo fonte ou sistemas de controle de revisão, são um mecanismo utilizado para
manter versões diferentes de cada arquivo do código-fonte de um software. Deste modo
quando você modifica um arquivo, ainda pode acessar suas versões anteriores. São
também um mecanismo colaborativo para que pessoas envolvidas no mesmo projeto
possam trabalhar paralelamente [Humble e Farley 2010].
2
Informação sobre a reação de um usuário ou produto utilizado como base para melhoria.

6. Para este estudo utilizaremos a ferramenta GitHub, pois é um serviço hospedado
na nuvem, diminuindo a complexidade de alguém na empresa ter a preocupação com a
manutenção de um servidor de controle de versao, largamente utilizado atualmente com
quase 19 milhões de repositórios. Permite ainda que sejam feitos o cadastro de issues3
,
milestones4
e ainda revisão por pares dos commits5
realizados, práticas estas que estão
contidas nas metodologias ágeis [GitHub 2014].
3.6 Servidor de Integração Contínua
Estes softwares possuem duas funcionalidades basicamente, o primeiro é poder executar
por periodos longos um fluxo de trabalho simples em intervalos regulares. O segundo é
fornecer uma visão rápida e simples dos resultados dos processos que foram então
executados, notificando sobre o sucesso ou falha dos builds6
e testes. Estes serviços
normalmente disponibilizam uma interface web para que possamos olhar com mais
clareza tudo o que está acontecendo no momento ou também nos permitindo olhar para
o passado [Humble e Farley 2010].
Figura 2. Screenshot do Jenkins com processos já executados
Para este estudo de caso iremos utilizar a ferramenta Jenkins (Figura 2), um
serviço de integração continua open-source, sendo o seu uso gratuito. Possui uma
interface web amigável, é de fácil instalação e manutenção, possuindo vários plugins
que facilitam ainda mais o trabalho como por exemplo, o plugin para o github, onde
estaram armazenados os projetos deste estudo e também plugins de framworks de testes,
possibilitando uma visualização mais rápida do resultado dos testes.
4. Estudo de Caso
O estudo de caso foi realizado com base em sistemas Web de grande complexidade,
onde para cada cliente de um produto, um projeto especifico de layout precisa ser
3
Problema encontrado, as vezes também chamado de erro.
4
Marca fases importante no ciclo de um projeto.
5
Salvar o código desenvolvido.
6
Ato de construir algo.

7. montado, porém o backend7
é quase sempre o mesmo. As etapas de desenvolvimento da
aplicação e de testes eram bastante trabalhosas, uma vez que não eram utilizadas muitas
ferramentas que automatizassem tais processos.
Esse excesso de trabalho manual acabava gerando sempre uma lista grande de
defeitos encontrados na aplicação, pois o desenvolvedor não se atinha a criar testes
unitários ficando todo o teste da aplicação a cargo do testador que fazia grande parte
deste trabalho também de forma manual. Considerando isso, podemos facilmente
perceber que existia uma grande demora entre uma implementação ou correção de uma
feature8
até o momento que ela entraria de fato em produção, algo em torno de 6 horas,
e ainda sem garantir que a grande maioria dos defeitos seria encontrada. A Figura 3
ilustra os passos necessários para realização de um deploy, depois que o testador tivesse
dado seu aval.
Figura 3. Processo de deploy manual da aplicação
Como todo trabalho manual que é realizado está sujeito a erros, este tipo de
atividade também pode incorrer em erros, seja trocando o nome de um diretório ou o
número de uma versão. Outro problema era em relação aos testes da aplicação, que eram
todos feitos de forma manual, testando todas as regras de negócio, funcionalidades e
tempo de resposta por exemplo.
Como solução dos problemas citados e também para tornar mais produtivo o
trabalho no time foram então sugeridas algumas práticas de integração contínua para que
7
Parte de um programa que não é diretamente acessada pelo usuário.
8
Funcionalidade de um software.

8. pudessemos analisar se haveria uma real melhoria na qualidade e no tempo de execução
das tarefas. No contexto do time estudado, algumas práticas faziam mais sentido e estas
serão explanadas a seguir.
4.1 Automação de testes
O primeir ponto abordado pela equipe foi em relação a criação de uma suite de testes
para automatizar parte deste trabalho. O ideal seria que todo o código desenvolvido
fosse coberto por testes, porém como estávamos iniciando essa atividades, optou-se pela
realização de testes unitários para verificarmos qual seria o ganho com esta prática.
A proposta foi de escrever códigos de testes unitários que cobrissem todos os
cenários possíveis para cada função executada no código. Para que isso fosse possível
utilizamos a bibliota de testes do JavaScript chamada Jasmine que utiliza por baixo o
PhantomJS que é um headless browser, evitando assim que seja necessário instanciar
um navegador para a execução dos testes.
Como a parte do software que se está testando tem dependencias com outros
softwares que nao fazem parte do escopo deste projeto, utilizou-se uma outra
ferramenta, Sinon.js, para mockar as interações com os componentes necessários. Os
testes foram então isolados da aplicação principal, tendo uma estrutura independente
onde é mais fácil de realizar uma manutenção.
Foi então criada uma suite com aproximadamente quinhentos casos de testes
(esse número varia conforme o projeto), que são executados em menos de um segundo,
possibilitando que o desenvolvedor consiga identificar algum erro (Figura 4) com muito
mais rapidez, podendo corrigí-lo prontamente (Figura 5) e também auxilie na melhora
da qualidade do código que é entregue ao testador.
Figura 4. Testes executados com erro

9. Figura 5. Testes executados com sucesso
Estas ferramentas possibilitam ainda que se possa verificar a quantidade de
linhas de código tem cobertura por testes, como podemos ver na Figura 6. Para este
projeto em específico a parte que está sendo testada tem 1.661 linhas de código, das
quais 1.397 possuem no mínimo um teste passando por elas.
Figura 6. Sumário de cobertura de testes
Com essa prática, conseguiu-se diminuir em 30% o número de erros encontrados
na fase de testes, pois passaram a ser encontrados ainda na fase de desenvolvimento.
Isso impacta também na equipe de testes que acaba ficando mais livre para criar novos
casos de testes, testar outras funcionalidades não cobertas por este código ou ainda
implementar novos testes automáticos, como testes de aceitação e integração, por
exemplo.
4.2 Build Automatizado
Outra tarefa que demandava muito tempo e era suscetível a erros era a realização dos
builds do projeto. Para esta prática, buscamos uma ferramenta que suportasse javascript
que é a linguagem utilizada no desenvolvimento da aplicação. Adotamos então uma
ferramenta de build específica para node.js, o Grunt. A partir desta ferramenta,
executamos de maneira automática os diferentes passos envolvidos no desenvolvimento
da aplicação.
Essa ferramenta necessita que seja desenvolvida uma feature (Gruntfile.js) para
interpretar o que se deve fazer. Neste caso o build automaticamente concatena, minifica
e ofusca os diferentes arquivos de javascript, além de roda automaticamente os testes

10. unitários implementados no passo anterior quando se roda o comando “grunt”. Através
deste comando também é possível que sejam geradas versões estáveis da aplicação,
onde automaticamente ele empacota e tagueia uma nova versão com o comando “grunt
release:vX.Y.Z”.
4.3 Controle de Versão
O controle de versão já era utilizado pela time, porém de maneira muito simples e
usando a ferramenta SVN. A melhoria se iniciou neste ponto adotando outra ferramenta
de controle de versão, o Github, pois já era utilizado largamente por outros times na
empresa, possui um repositório distribuido e com serviço na nuvem, nos permitindo ter
acesso a aplicação em qualquer lugar que contasse com acesso a internet.
A segunda parte da melhoria é em relação ao processo de uso, onde antes se
tinha apenas os desenvolvedores fazendo seus commits e em seguida empacotando o
código para então os testes serem realizados, agora é necessário que seja feito uma
revisão com o seu par, seja ele outro desenvolvedor ou um tester, para com o aval de
ambos o código seja commitado e então liberado.
Outra prática adotada foi a de sempre gerar uma tag quando uma versão estiver
estável e possa ser então disponibilizada para o cliente final. Com isso, caso uma versão
posterior sofra algum problema que não tenha sido identificado anteriormente, fica
muito mais fácil de se reverter o sistema para a última versão estável.
Além destas duas práticas citadas acima, adotou-se um esquema de
versionamento que segue o “semver9
” (major.minor.patch), onde o MAJOR segue a
versão da API que o sistema utiliza, o MINOR é incrementado sempre que uma nova
feature é desenvolvida e o PATCH é incrementado quando existe a correção de algum
bug da versão.
4.4 Commits constantes
Outra prática adotada foi a de realizar commits constante, pois quanto mais tempo o
código fica sem ser salvo, maior o risco de ter que fazer um merge para juntar partes que
foram desenvolvidas por outras pessoas. A complexidade do trabalho aumenta se a
quantidade de merges também for grande, podendo ocasionar em mais erros no código.
Porém é importante lembrar que não se deve fazer commits a todo instante, pois
pode-se com isto, perder a rastreabilidade do que foi feito, dificultando a revisão e
também a resolução de problemas que podem vir a surgir. Neste ponto, adotou-se então
a prática de revisão de commits, para que outra pessoa também possa opinar se seus
commits também estão bons, não apenas o seu código.
4.5 Não commitar código quebrado
Uma prática essencial para a Integração Contínua, é tratar o controle de versão
como algo sagrado, ou o mais próximo disto. Se não se pode confiar que o código que
está no trunk (ou master) é limpo e de confiança, fica difícil resolver os
problemas depois que eles já saíram da cabeça do desenvolvedor. Para a resolução deste
9
Regra semântica de versionamento, http://semver.org/

11. problema, adotou-se a prática de rodar localmente o projeto, fazendo o build automático
dele, onde já são executados também todos os testes unitários mencionados na primeira
prática deste capítulo, antes de fazer o push do código para o Github.
Após o envio do código para o repositório, um job de build é automaticamente
disparado no servidor de integração contínua (Jenkins), onde caso o build gere algum
erro, o responsável é imediatamente notificado, podendo tomar uma ação imediata para
a correção do problema, refazendo o processo até que o build fique estável.
4.6 Deploy automatizado
A última melhoria adotada é em relação a prática de entrega contínua, onde o processo
para disponibilizar uma nova versão em produção seja o mais automático e transparente
possível. Para que isto fosse algo que funcionasse 100%, deveriamos ter todos os testes
possíveis implementados nos projetos (unitários, aceitação, integração), porém isso
ficará para um segundo momento.
Neste momento foi implementado um job que faz a publicação automática de
uma versão depois que ela passa por todos os testes unitários (automáticos) e também
pelos testes manuais exploratórios que a equipe de testes realiza. Como vemos na Figura
2, foram criados jobs de publish (publicação) que são disparados atualmente de forma
manual, porém executando automaticamente todo o processo mostrado na Figura 3
apenas informando na hora da execução qual é o número da tag que deverá ser
publicada em produção.
5. Conclusão
Conforme proposto, este artigo mostrou a implementação de algumas técnicas de
integração contínua e automação de testes.
Em cada prática pudemos verificar que houve uma melhora no desempenho do
time e no desempenho do processo executado, tornando-o mais automático com menos
probabilidade de ocorrerem erros. A prática de automação dos testes unitário se mostrou
bastante eficiente, uma vez que a mesma quantidade de testes para serem executados de
forma manual levava em torno de 3 horas de um membro da equipe, geralmente o tester.
Considerando que as equipes geralmente são formadas por até 3
desenvolvedores, 2 designers e apenas 1 tester esse trabalho era bastante exaustivo e
suscetível a erros.
Outra prática que obteve bastante aceitação e gerou um impacto forte no
processo foi o build e o deploy automático, uma vez que desenvolvedores não precisam
mais executar as tarefas repetitivas dos passos de build e deploy da aplicação, tendo
mais tempo para trabalhos mais criativos e menos repetitivos.
Por fim, agora conseguimos obter feedbacks muito mais rápidos das aplicações,
integrando o código continuamente, investindo tempo na automação de tarefas e testes,
podendo encontrar defeitos antecipadamente e tornando então mudanças no software
muito menos problemáticas.

12. Referências
Beck, K., Beedle, M., Bennekum, A. van and et al (2001) “Manifesto para
Desenvolvimento Ágil de Software”, http://www.agilemanifesto.org/iso/ptbr/,
Janeiro
Dustin, E; Rashka, J; Paul, J. (1999), Automated Software Testing: Introduction,
Management, and Performance. 1st
edition.
Fowler, M. (2013) “ContinuousDelivery”,
http://martinfowler.com/bliki/ContinuousDelivery.html, Janeiro.
Fowler, M. (2006) “Continuous Integration”,
http://martinfowler.com/articles/continuousIntegration.html, Janeiro.
GitHub. (2014) “Field-tested tools for any project”, https://github.com/features, Janeiro.
Humble, J.; Farley, D. (2010), Continuous Delivery: Reliable Software Releases through
Build, Test, and Deployment Automation. 1st
edition.
Rouse, M. (2014) “Automated software testing”,
http://searchsoftwarequality.techtarget.com/definition/automated-software-testing,
Janeiro.
Wells, Don. (2009) “Agile Software Development: A gentle introduction”,
http://www.agile-process.org/, Janeiro.