CONVERSA INICIAL

Veremos os conceitos de integração contínua serão apresentados, dando

continuidade aos conceitos de testes de integração já comentados. No segundo
tema, serão abordados os conceitos de testes de validação e, no terceiro tema, o
conceito de testes de sistemas. No quarto tema, serão tratados os testes de
versão, e, no quinto tema, o conceito de testes de usuários.

CONTEXTUALIZANDO

Integração contínua, que é o primeiro tema desta fase, trata da evolução

dos testes de integração de sistemas. É um conceito que foi definido nos anos
2000 e que evoluiu dentro da prática de DevOps, que integra as áreas de
desenvolvimento e de operações de TI. DevOps é uma importante tendência de
evolução em organizações envolvidas com o desenvolvimento de produtos de
software.
Já os testes de validação e de sistema, são feitos, em geral, por equipes
de teste separadas da equipe de desenvolvimento de software. Esses tipos de
teste encerram o ciclo de testes de software já apresentados, que compreende os
testes realizados pela organização responsável pelo desenvolvimento de um
sistema de software. Com relação aos testes de responsabilidade de uma
organização de desenvolvimento de software, são tratados ainda os testes de
versão, realizados para garantir o bom funcionamento de uma versão gerada de
um sistema.
Por fim, serão discutidos os testes de usuário. Esses testes são importantes
para que os usuários apresentem um retorno à equipe de desenvolvimento sobre
como o sistema deve funcionar na prática. Outros testes são importantes para
garantir que o sistema está funcionando de acordo com o entendimento dos
usuários, condicionando a liberação do pagamento pelo sistema para a
organização que o desenvolveu.

INTEGRAÇÃO CONTÍNUA
Integração contínua é uma prática que encoraja desenvolvedores a integrar
o seu código com um branch principal, ou um repositório compartilhado, de forma
frequente. Em vez de construir novas funcionalidades de forma isolada e integrá-
las no fim do ciclo de desenvolvimento, o código é integrado com o repositório
compartilhado por cada desenvolvedor por várias vezes durante o dia (Ellingwood,
2017).
O termo “integração continua” originou-se com o processo de
desenvolvimento Extreme Programming (XP), como uma das suas doze práticas
originais. Algum tempo depois, foi lançado o CruiseControl, primeiro servidor de
integração contínua. Hoje, no mundo, cerca de 50% das empresas utilizam
integração contínua (Fernandes, 2015).
A maneira como se realiza a integração mudou desde a concepção original
do XP. Atualmente, envolve construir e testar uma aplicação de forma automática
e em intervalos frequentes em um servidor de integração. Os desenvolvedores
realizam commits de pequenas atualizações regularmente, sendo notificados
rapidamente se suas modificações provocam falhas no sistema em
desenvolvimento (Moreira, 2010).
A integração frequente do código não oferece qualquer garantia sobre a
qualidade do novo código, ou funcionalidade. Em muitas organizações, a
integração é trabalhosa porque processos manuais são utilizados para garantir
que o código siga padrões, não introduza defeitos e não invalide funcionalidades
existentes. A integração frequente pode criar atritos quando o nível de automação
não é o suficiente para suportar as medidas de garantia de qualidade estipuladas.
Para resolver esse atrito com o processo de integração, na prática, a
integração contínua se baseia em conjuntos robustos de testes, além de um
sistema automatizado para executar esses testes. Quando um desenvolvedor
efetua uma operação Merge no repositório principal, processos automatizados
iniciam um build do novo código. Depois, conjuntos de testes são executados
nesse novo build para verificar se algum problema de integração foi introduzido.
Se o build ou a fase de testes falha, o time é avisado para que possam trabalhar
para corrigir o build.
O objetivo final da integração contínua é fazer com que a integração seja
um processo simples e de repetibilidade, que faça parte do fluxo de trabalho diário
para reduzir custos e corrigir defeitos o mais rápido possível. É fundamental para
o sucesso da estratégia trabalhar para fazer com que o sistema seja robusto,
automatizado e rápido enquanto uma cultura de interação frequente e de
responsividade para problemas de buildé cultivada (Ellingwood, 2017). Na figura
1, segue uma visão geral sobre integração contínua.
Figura 1 — Visão geral da prática de integração contínua

Relatórios
Métricas de código
Review Running Tested Features
— Diagramas de classes
> Builds com sucesso
Feedback alerta de problemas

ni, À

commit y Pull vw

ci Script
Controle de Versão Máquina Compitar código fonte,
executar testes,
> de Integração gerar relatórios,
disponibilizar versão
Desenvolvedor
Fonte: Moreira, 2010.

A prática de integração contínua funciona da seguinte maneira (Moreira,

2010):
1. O desenvolvedor envia o código para o controle de versão (SVN, CVS etc.).
Enquanto isso, o servidor de integração contínua monitora o repositório de
controle de versão, buscando por modificações.
Logo após um commit ser efetuado, o servidor identificará a mudança no
nn

código. Inicia-se o processo de build, obtendo-se os arquivos do controle

de versão. Assim, o script de build é executado, testes são realizados,
relatórios são gerados, e todo o projeto é integrado.
. O servidor de integração envia por e-mail, ou por outras formas de
[o

notificação, o resultado da execução do build para usuários específicos do

projeto.
O servidor volta ao estado de monitoramento de mudanças no repositório.
Em

Um comportamento importantíssimo: essa arquitetura força a equipe a

manter sempre em funcionamento todo o código fonte que existir no repositório,
adicionando mais controles a possíveis problemas de implementação ou de
integração que possam acontecer (Moreira, 2010).

40
qu
 O conceito de integração contínua evoluiu dentro do contexto de DevOps,
sendo estendido para as práticas de entrega e implantação contínuas. O termo
DevOps se refere à integração entre a área de desenvolvimento (Dev) e a área
de operações (Ops) de TI, agilizando a entrega de funcionalidades de sistemas.

TESTES DE VALIDAÇÃO
Os testes de validação começam no fim dos testes de integração e se
concentram em ações visíveis pelo usuário, além de saídas do sistema
reconhecíveis pelo usuário.
Um princípio geral de boas práticas de engenharia de requisitos é o de que
os requisitos devem ser testáveis; isto é, o requisito deve ser escrito para que um
teste possa ser concebido para esse requisito. Um testador pode então verificar
se o requisito foi satisfeito. A metodologia de testes de validação, portanto, é uma
abordagem sistemática para o planejamento de testes, em que é possível obter
um conjunto de testes para cada requisito do sistema.
A validação de software é conseguida por meio de uma série de testes que
demonstram conformidade com os requisitos. Um plano de teste descreve as
classes de testes a serem conduzidas, e um procedimento de teste define casos
de teste específicos. Esses casos de teste são projetados para garantir que todos
os requisitos funcionais sejam satisfeitos, que todo o conteúdo seja preciso e
corretamente apresentado, todos os requisitos de desempenho sejam alcançados
e que a documentação esteja correta, e que a usabilidade e outros requisitos
sejam atendidos (Pressman, 2010; Somerville, 2011).
Depois de cada caso de teste de validação ter sido realizado, existe uma
de duas condições possíveis (Pressman, 2010):

1. A funcionalidade está em conformidade com a especificação e é aceita.

2. Um erro de especificação é descoberto e uma lista de deficiências é criada.

Os erros descobertos nessa fase de um projeto raramente podem ser

corrigidos antes da entrega programada (Pressman, 2010).

Cenários de testes

A abordagem de cenários de testes consiste no desenvolvimento de

cenários típicos de utilização, utilizados para desenvolver casos de testes de
validação para o sistema. Um cenário é uma história que descreve uma maneira
pela qual o sistema pode ser usado. Os cenários devem ser realistas, nos quais

41
os usuários reais do sistema devem se relacionar com eles. Se forem utilizados
cenários de utilização como parte do processo de engenharia de requisitos do
sistema, então pode ser possível reutilizá-los como cenários de teste.
Um cenário de testes deve ser uma história narrativa mais próxima possível
da realidade de utilização do sistema e bastante complexa. Deve motivar as partes
interessadas; isto é, as partes devem se relacionar com o cenário e acreditar que
é importante que o sistema passe pelo teste. Além disso, o cenário deve ser de
fácil avaliação (Somerville, 2011).

TESTES DE SISTEMA

Os testes de sistema são uma série de testes diferentes, cujo objetivo

principal é a execução completa do sistema. Embora cada teste tenha uma
finalidade específica, todos são executados para verificar se os elementos do
sistema foram devidamente integrados, e se desempenharam suas
funcionalidades da forma esperada. Nas seções a seguir, são descritos os tipos
mais importantes de testes de sistema de software (Pressman, 2010).

Teste de recuperação de falhas

Muitos sistemas devem se recuperar de falhas e continuar o

processamento com pouco, ou nenhum, tempo indisponível. Em alguns casos, um
sistema deve ser tolerante a falhas, isso é, falhas de processamento não devem
fazer com que o sistema aborte. Em outros casos, uma falha de sistema deve ser
corrigida dentro de um período específico. Caso contrário, um grande prejuízo
econômico poderá ocorrer para a organização.
O teste de recuperação de falhas é um teste de sistema que força o
software a falhar de várias maneiras, verificando se a recuperação é executada
corretamente. Se a recuperação for automática (realizada pelo próprio sistema),
os mecanismos de reinicialização, checkpoint e recuperação de dados são
avaliados quanto à sua exatidão. Se a recuperação requer intervenção humana,
o tempo médio de reparação é avaliado para determinar se está dentro de limites
aceitáveis (Pressman, 2010).

Teste de segurança

Qualquer sistema baseado em computador que administra informações

sensíveis, ou que provoque ações que possam prejudicar indevidamente (ou
beneficiar) indivíduos, é um alvo para uma invasão imprópria ou ilegal. A invasão
42
abrange uma ampla gama de atividades: hackers que tentam invadir sistemas por
diversão, funcionários descontentes que tentam invadir o sistema por vingança,
indivíduos desonestos que tentam invadir o sistema pelo ganho pessoal ilícito.
Testes de segurança tentam verificar se os mecanismos de proteção
incorporados a um sistema, de fato, o protegerão de uma invasão.
Durante o teste de segurança, o testador desempenha o papel do indivíduo
que deseja invadir o sistema. Todas as possibilidades consideradas para o teste
são avaliadas. Entre essas possibilidades, o testador pode (Pressman, 2010):

e tentar adquirir senhas;

e atacar o sistema com um software personalizado, projetado para
quebrar as defesas que foram construídas;
e dominar o sistema, negando o serviço a outros, ou pode provocar erros
do sistema propositadamente, na esperança de efetuar uma invasão
durante a recuperação;
* navegar por dados inseguros, na esperança de encontrar a chave para
a entrada no sistema.

Testes de estresse

As etapas anteriores de teste de software resultaram na avaliação completa

de funções e de desempenho do sistema. Os testes de estresse são projetados
para exercitar programas com situações anormais. O teste de estresse executa
um sistema de forma que exige recursos em quantidade, frequência ou volume
anormais. Por exemplo (Pressman, 2010):

e Testes especiais podem ser projetados para que gerem dez

interrupções por segundo, quando uma ou duas é a taxa média.
e Astaxas de dados de entrada podem ser aumentadas por uma ordem
de grandeza para determinar como as funções de entrada do sistema
responderão.
e Casos de teste que exigem memória máxima, ou outros recursos, são
executados.
e Casos de teste que podem causar uma batida em um funcionamento
virtual sistema são projetados.

43
 e Casos de teste que podem causar uma procura excessiva por dados
do disco rígido são criados. Essencialmente, o testador tenta "quebrar"
o programa.

Testes de desempenho

Para sistemas em tempo real e embutidos, um software que fornece as

funcionalidades necessárias, mas que não esteja em conformidade com requisitos
de desempenho, é inaceitável. Testes de desempenho são projetados para testar
o desempenho em tempo de execução do software, no contexto de um sistema
integrado. Esses testes ocorrem em todas as etapas do processo de testes.
Mesmo nos testes unitários, o desempenho de um módulo individual pode ser
avaliado. No entanto, somente quando todos os elementos do sistema estão
integrados é que os testes reais de desempenho do sistema podem ser
executados.
Os testes de desempenho são frequentemente associados ao teste de
estresse, e geralmente requerem instrumentação de hardware e software. Ou
seja, muitas vezes é necessário medir a utilização de recursos (por exemplo,
ciclos de processamento) de forma rigorosa. Instrumentação externa pode
monitorar intervalos de execução, eventos de log (por exemplo, interrupções) à
medida que ocorrem. Ao instrumentar um sistema, o testador pode descobrir
situações que levam à degradação e possível falha no sistema (Pressman, 2010).

Testes de implantação

Em muitos casos, o sistema deve ser executado em uma variedade de

plataformas, abrangendo mais do que um ambiente de sistema operacional.
Testes de implantação, às vezes chamados de testes de configuração, exercitam
o software em cada ambiente em que será executado. Além disso, o teste de
implantação examina todos os procedimentos de instalação e softwares de
instalação especializados (por exemplo, "instaladores", que serão utilizados pelos
clientes, e toda a documentação que será utilizada para apresentar o software aos
usuários finais (Pressman, 2010).

TESTES DE VERSÃO

Os testes de versão têm o propósito de testar uma versão específica de um

sistema, que é destinada a ser usada fora da equipe de desenvolvimento.
Normalmente, a versão do sistema é para clientes e usuários. Em um projeto
44
complexo, no entanto, a versão poderia ser para outras equipes que estão
desenvolvendo sistemas relacionados. Para produtos de software, a versão
poderia ser para a gestão de produtos que, em seguida, prepara-o para venda
(Somenville, 2011). Existem duas distinções importantes entre os testes de versão
e os testes de sistema durante o processo de desenvolvimento (Somerville, 2011):

e Uma equipe separada, que não tenha participado do desenvolvimento

do sistema, deve ser responsável pelos testes de versão.
e Os testes feitos pela equipe de desenvolvimento devem se concentrar
na descoberta de erros no sistema. O objetivo dos testes de versão é
verificar se o sistema atende aos seus requisitos, além de verificar se
a versão é boa o suficiente para uso externo (teste de validação).

O principal objetivo do processo de teste de versão é convencer o

fornecedor do sistema de que a versão do sistema em testes é boa o suficiente
para ser utilizada. Se assim for, pode ser lançada como um produto ou uma
entrega. Os testes de versão, portanto, têm que mostrar que o sistema fornece as
funcionalidades, o desempenho e a confiabilidade especificados, e que ele não
falha durante o uso normal. Deve estar em conformidade com todos os requisitos
do sistema, não apenas com os requisitos definidos pelos usuários.
Os testes de versão geralmente são um processo de testes de caixa preta,
em que são derivados da especificação do sistema. O sistema é tratado como
uma caixa preta, cujo comportamento pode ser determinado apenas pelo estudo
de suas entradas e os resultados relacionados. Outro nome para esse tipo de
testes é “testes funcionais”. Isso porque o testador está apenas preocupado com
a funcionalidade, e não com a implementação do software (Somerville, 2011).

TESTES DE USUÁRIO

Os testes de usuário ou de cliente são um estágio no processo de testes

em que usuários ou clientes fornecem informações e orientações sobre os testes
do sistema. Isso pode envolver testes formais de um sistema que foram
encomendados a um fornecedor externo. Pode também ser um processo informal,
no qual os usuários experimentam um novo software para avaliação. Testes de
usuário são essenciais, mesmo quando testes de sistema e de versão tenham
sido realizados. A razão para isso é que a influência dos usuários tem um efeito
importante na confiabilidade, no desempenho, na usabilidade e na robustez de
um sistema.
45
 É praticamente impossível para um desenvolvedor replicar o ambiente de
funcionamento real da maior parte de sistemas computacionais. Por exemplo, um
sistema que se destina a ser utilizado em um hospital pode ser utilizado em um
ambiente clínico, em que outras coisas estão acontecendo, como emergências de
pacientes, conversas com parentes etc. Tudo isso afeta o uso de um sistema, mas
os desenvolvedores não podem incluir essas situações em seu ambiente de teste
(Somerville, 2011).
Na prática, existem três tipos diferentes de testes de usuários (Somerville,
2011):
1. Testes alfa, em que os usuários do software trabalham com a equipe de
desenvolvimento para testar o software no ambiente de desenvolvimento.
2. Testes beta, em que uma versão do softwareé disponibilizada aos usuários
para permitir testes em ambientes reais, nos quais problemas podem ser
descobertos e repassados para os desenvolvedores.
3. Testes de aceitação, em que os clientes testam um sistema para decidir se
ele está pronto ou não para ser aceito e implantado no ambiente de
produção.

Nos testes alfa, usuários e desenvolvedores trabalham juntos para testar

um sistema durante o seu desenvolvimento. Isso significa que os usuários podem
identificar problemas que não são aparentes para a equipe de testes de
desenvolvimento. Os desenvolvedores implementam o software a partir dos
requisitos, mas estes geralmente não refletem outros fatores que afetam a prática
da utilização do software. Os usuários podem, portanto, fornecer informações
sobre práticas que ajudam na concepção de testes mais realistas.
Os testes alfa são frequentemente usados com o desenvolver produtos de
software que são vendidos como sistemas encolhidos. Os usuários desses
produtos podem estar dispostos a se envolver no processo de testes alfa porque
isso lhes oferece informações antecipadas sobre recursos do novo sistema, que
eles podem explorar. Isso também reduz o risco de mudanças imprevistas, que
podem ter efeitos disruptivos em seus negócios. No entanto, testes alfa também
podem ser utilizados quando o software personalizado está sendo desenvolvido.
Métodos ágeis, como XP, defendem o envolvimento dos usuários no processo de
desenvolvimento, e que os usuários devem desempenhar um papel fundamental
na concepção de testes para o sistema.

46
 Os testes beta ocorrem quando uma versão inicial, às vezes inacabada, de
um sistema, é disponibilizada a clientes ou usuários para avaliação. Os testadores
beta podem ser um grupo selecionado de clientes ou usuários iniciais do sistema.
Alternativamente, o software pode ser disponibilizado publicamente para
qualquer pessoa que esteja interessada. Testes beta são usados principalmente
para produtos de software que são usados em muitos ambientes diferentes (em
oposição a sistemas personalizados, que são geralmente usados em um ambiente
definido). É impossível que os desenvolvedores de produtos conheçam e
repliquem todos os ambientes em que o software será usado. Testes beta são,
portanto, essenciais para descobrir problemas de interação entre o software e os
recursos do ambiente em que ele é usado. Os testes beta também são uma forma
de marketing, visto que os clientes aprendem sobre o funcionamento do sistema
e o que ele pode fazer por eles (Somerville, 2011).

Testes de aceitação

Os testes de aceitação, feitos após os testes de liberação, são uma parte

inerente do desenvolvimento de sistemas personalizados. Esse tipo de teste
envolve um cliente testando formalmente um sistema para decidir se deve ou não
ser aceito. A aceitação implica que o pagamento deve ser feito para a organização
que desenvolveu o sistema (Somenville, 2011). Existem seis etapas no processo
de testes de aceitação, como pode ser visto na figura 2 (Somerville, 2011):

Figura 2 — Testes de aceitação

Executar
testes de
aceitação
Fonte: Somenville, 2011.

1. Definir critérios de aceitação. Essa etapa deve, idealmente, ocorrer no

início do processo, antes da assinatura do contrato do sistema. Os critérios
de aceitação devem fazer parte do contrato do sistema e devem ser
acordados entre o cliente e os desenvolvedores. Na prática, no entanto,
pode ser difícil definir critérios tão cedo no processo. Os requisitos

47
 detalhados podem não estar disponíveis e pode haver mudanças
significantes de requisitos durante o processo de desenvolvimento.
Planejamento dos testes de aceitação. Isso envolve a decisão sobre os
mn

recursos, o tempo e o orçamento para os testes de aceitação, além de

estabelecer um cronograma de testes. A aceitação do plano de testes
também deve discutir a cobertura necessária dos requisitos e a ordem em
que os recursos do sistema são testados. Deve definir riscos para o
processo de testes, como falhas do sistema e desempenho inadequado, e
deve-se discutir como esses riscos podem ser mitigados.
Derivar testes de aceitação. Uma vez que os critérios de aceitação forem
so

estabelecidos, testes devem ser projetados para verificar se um sistema é

ou não aceitável. Os testes de aceitação devem compreender as
características funcionais e não funcionais (por exemplo, desempenho) do
sistema. Deveriam, idealmente, fornecer cobertura completa dos requisitos
do sistema. Na prática, é difícil estabelecer critérios de aceitação totalmente
objetivos. Muitas vezes, há argumentos sobre se um teste mostra, ou não,
que um critério foi atingido.
Executar os testes de aceitação. Nesse passo, os testes de aceitação
>

são executados no sistema. Idealmente, isso deve ocorrer no ambiente em

que o sistema será usado, mas isso pode ser impraticável. Portanto, um
ambiente de testes de usuário pode ter que ser configurado para executar
esses testes. É difícil automatizar esse processo, pois parte dos testes de
aceitação pode envolver interações entre usuários finais e o sistema. Pode
ser necessário algum treinamento dos usuários.
Negociar resultados do teste. É muito improvável que todos os testes de
a

aceitação definidos passem, e que não haverá problemas com o sistema.

Se esse for o caso, então o processo de testes de aceitação está completo,
e o sistema pode ser entregue. É mais provável, todavia, que alguns
problemas sejam encontrados. Nesses casos, o desenvolvedor e o cliente
têm que negociar para decidir se o sistema é bom o suficiente para ser
colocado em utilização. Os clientes também devem concordar com as
respostas dos desenvolvedores sobre os problemas identificados.
Rejeitar/aceitar o sistema. Essa etapa envolve uma reunião entre os
2

desenvolvedores e os clientes para decidir se o sistema deve ou não ser

aceito. Se o sistema não é bom o suficiente para utilização, então é

48
 necessário que os problemas identificados sejam corrigidos. Uma vez que
uma nova versão seja liberada com as correções, a fase de testes de
aceitação é reiniciada.

Em métodos ágeis, como XP, os testes de aceitação têm um significado

bem diferente. De forma geral, definem a ideia de que os usuários devem decidir
se o sistema é ou não aceitável. No entanto, no XP, o usuário faz parte da equipe
de desenvolvimento (ou seja, é um testador alfa) e fornece os requisitos do
sistema em termos de histórias de usuários. O usuário também é responsável por
definir os testes, que validam o software desenvolvido quanto à capacidade de
suportar a história de usuário. Os testes são automatizados, e o desenvolvimento
não prossegue enquanto os testes de aceitação da história de usuário não tenham
passado. Não existe, portanto, uma atividade de testes de aceitação separada.
Um problema com o envolvimento do usuário é garantir que o usuário
incorporado na equipe de desenvolvimento seja um usuário "típico", com
conhecimento geral de como o sistema será usado. Pode ser difícil encontrar esse
usuário e, portanto, os testes de aceitação podem na verdade não ser um
verdadeiro reflexo da prática.
Além disso, os testes automatizados limitam profundamente a flexibilidade
dos testes interativos. Para tais sistemas, os testes de aceitação podem exigir
grupos de usuários finais para usar o sistema, como se fosse parte de seu trabalho
diário.
Pode-se pensar que os testes de aceitação compreendem uma questão
contratual clara. Se um sistema não passa pelos seus testes de aceitação, então
não deve ser aceito, e o pagamento não deve ser liberado. No entanto, a realidade
é mais complexa. Os clientes desejam utilizar o software assim que puderem,
devido aos benefícios de sua implantação imediata. Eles podem ter comprado
novos equipamentos, treinado pessoal e efetuado mudanças em seus processos.
Eles podem estar dispostos a aceitar o software, independentemente dos
problemas, porque os custos de não usar o software são maiores do que os custos
de lidar com os problemas decorrentes da ausência dele. Portanto, o resultado
das negociações pode ser a aceitação condicional do sistema. O cliente pode
aceitar o sistema para que a implantação possa começar. O provedor do sistema
concorda em corrigir problemas urgentes, e entregar uma nova versão para o
cliente o mais rápido possível (Somerville, 2011).

49
FINALIZANDO

Foi feita uma descrição sobre integração contínua, bem como foi concluída
a descrição dos conceitos de testes de integração, comentados na etapa anterior.
Depois, foram apresentados os conceitos de testes de validação. Em seguida, foi
feita uma visão geral sobre testes de sistema. No tema seguinte foi apresentado
o conceito de testes de versão, em que uma versão específica de um sistema é
testada. No último tema, foram comentados os testes de usuário, finalizando o
ciclo de vida do processo de testes no contexto de desenvolvimento de software.

50
==
REFERÊNCIAS

ELLINGWOOD, J. An Introduction to Continuous Integration, Delivery, and

Deployment. Digital Ocean, 10 maio 2017. Disponível em:
<https://www .digitalocean.com/community/tutorials/an-introduction-to-continuous-
integration-delivery-and-deployment>. Acesso em: 31 jan. 2018.

FERNANDES, S. L. P. Maturidade da Integração Contínua. Octo Talks, 9 nov.

2015. Disponível em: <https://blog.octo.com/pt-br/maturidade-da-integracao-
continua/>. Acesso em: 31 jan. 2018.

MOREIRA, A. Integração contínua. 19 ago. 2010. Disponível em:

<http://siep.ifpe.edu.br/anderson/blog/?page
id=1015>. Acesso em: 31 jan. 2018.

PRESSMAN, R. Engenharia de software. 7. ed. São Paulo: McGraw-Hill, 2010.

SOMMERVILLE, |. Engenharia de software. 9. ed. Boston: Addison-Wesley,

2011.