Para total compreensão do processo de entrega contínua, é necessário descrever os seguintes pré-requisitos: gerência de configuração, integração contínua e testes de software.

Gerência de configuração

 

De acordo com Filho et al. (2010), para garantir a qualidade do software, é necessário utilizar a chamada Gerência de Configuração de Software (GCS). Ela tem como objetivogerenciar e controlar todos os artefatos relevantes ao projeto, e as relações que  existem entre eles.

É uma forma sistemática e organizada de controlar as modificações de um software tornando possível manter sua integridade ao longo do tempo. […] A Gerência de Configuração de Software tem especial importância na garantia da qualidade do software e no apoio a gestão de projetos […] (FILHO et al., 2010).

Para Humble e Farley (2014), a gerência de configuração é a base para todo o processo.  “É impossível fazer integração contínua e gerência de entregas e criar pipelines de entrega sem ela”.

 

Integração contínua

 

Dentro da GCS encontra-se a integração contínua, que “consiste em diminuir o ciclo de integração, tornando-o o mais frequente possível” (LOPES, 2011 apud ALMEIDA, 2014). Para Fowler (2006), a integração contínua “geralmente se refere a integração, construção e teste de código dentro do ambiente de desenvolvimento”.

Integração contínua é uma prática de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente (FOWLER, 2006).

De acordo com Garcia (2013), para que a integração seja efetiva, “é necessário verificar o funcionamento do código após as modificações, e para atender esta necessidade, o desenvolvimento em conjunto com a realização de testes é fundamental”. Se a execução da integração for bem sucedida, consegue-se atingir os seguintes benefícios:

Garantia que o código compila e que as funcionalidades testadas mantêm sua integridade e funcionamento esperados; uma potencial versão do software, que pode ser utilizada, por exemplo, pela equipe de QA para execução de testes (GARCIA, 2013).

Segundo Humble e Farley (2014), para implementar integração contínua é preciso um bom controle de versão, um processo automatizado de compilação e aceitação da equipe. Pode-se dizer  que a entrega contínua é uma extensão da integração contínua, o que torna a integração contínua obrigatória para se conseguir entrega contínua.

 

Estratégias de Testes de Software

 

Teste de software é uma disciplina muito ampla e será abordada brevemente dentro do contexto de entrega contínua, onde é de extrema importância, pois a estratégia de testes definida dará a confiança e o feedback necessários para que qualquer versão seja candidata a ir para produção.

Segundo Pressman (2011), teste é um conjunto de atividades que podem ser planejadas com antecedência e executadas sistematicamente. Para Humble e Farley (2014), “testar é uma atividade multifuncional que envolve todo o time e deve ser executada continuamente desde o início do projeto”.

De acordo com os autores, uma estratégia de testes é um processo de “identificação e priorização dos riscos do projeto e decisão de quais atitudes tomar para reduzi-las” (HUMBLE; FARLEY, 2014).

Para Pressman (2011) uma estratégia de teste deve acomodar tanto testes de baixo nível, para verificar se pequenos trechos de código fonte foram implementados corretamente, bem como testes de alto nível, que validam as principais funções do sistema de acordo com os requisitos do cliente.

Para criar uma eficiente estratégia de testes e garantir a entrega de uma aplicação de alta qualidade, os tipos de teste abaixo devem ser considerados:

 Testes de aceitação funcionais: garantem que os critérios de aceitação de um requisito sejam satisfeitos. Eles podem testar todos os tipos de atributos do sistema. Para Humble e
Farley (2014), quando os testes de aceitação obtêm sucesso, quaisquer que sejam os requisitos que eles testam podem ser considerados completos. Podem ser manuais, geralmente colocando a aplicação em um ambiente de homologação, e automatizados, que tem como alguns benefícios fornecer feedback mais rápido e reduzir o trabalho dos testadores.

Testes de aceitação não funcionais: são testes que verificam todas as qualidades de um
sistema que não sejam funcionalidades, como capacidade, disponibilidade e segurança. Taisrequisitos, apesar de não estarem diretamente ligados às funcionalidades do negócio, devem ser tratados com a mesma importância dos requisitos funcionais, pois, caso falhem, podem gerar inúmeros problemas para a aplicação como roubo de informações e indisponibilidade.

Já testes unitários são testes escritos pelos desenvolvedores e testam uma parte específica do código de forma isolada. De acordo com Humble e Farley (2014) é importante que pelo menos 80% do sistema seja coberto por testes unitários para um eficiente processo de entrega contínua.

Testes de integração testam a comunicação da aplicação com sistemas externos e até com módulos dentro da própria aplicação. Demonstrações são testes nos quais novas funcionalidades são demonstradas ao cliente. Importante ser frequente, para acelerar o feedback. Cabe mencionar também testes de componentes, testes de implantação, testes de usabilidade e testes exploratórios.

No próximo post será apresentado o principal padrão utilizado em entrega contínua de software. Acesse aqui.