Entrega Contínua

Tudo que você precisa saber sobre Entrega Contínua de Software – 5 – Estágios de Testes

Estágio de Testes de Aceitação Automatizados

 

Para Humble e Farley (2014) o objetivo do estágio de testes de aceitação é garantir que o sistema entrega o valor esperado ao cliente e atende aos critérios de aceitação. Caso haja falha nesse estágio, o pipeline deve ser interrompido e a equipe deve agir imediatamente.

Para que testes de aceitação sejam bem realizados e fáceis de manter, o processo de análise do software é importante, pois estes testes derivam dos critérios de aceitação acordados com o cliente. Então, faz-se necessários que os critérios de aceitação já sejam escritos com base no processo de automatização.

Uma abordagem que visa facilitar este processo é conhecida como BDD, Behavior-Driven Development, ou Desenvolvimento Guiado por Comportamento. De acordo com Humble e Farley (2014), uma das ideias centrais do BDD é que os critérios de aceitação devem ser escritos como as expectativas que o cliente tem sobre o comportamento da aplicação. Através dele, é possível executar esses critérios como testes da aplicação. Uma ferramenta bastante popular para automatização de testes escritos com BDD é o Cucumber, que permite a execução de tarefas escritas em linguagem de negócio. Cucumber é simples de utilizar e configurar e vem se tornando bastante popular.

Outra ferramenta que deve ser considerada para a automatização de testes de aceitação é o Selenium, ele tem como objetivo simular ações de um navegador, possibilitando reproduzir interações de usuários com o sistema e validar tais interações. Ainda consegue gerar relatórios com os resultados dos testes.

Uma boa prática para testes de aceitação é executá-los sempre em ambientes semelhantes ao de produção. Caso não seja possível, deve-se tentar utilizar uma versão mais reduzida deste. Uma tecnologia que pode ser empregada para facilitar este trabalho é o Docker que permite a implantação de aplicações de forma rápida e automatizada através de containers. Uma vez que a aplicação, ou ambiente, esteja empacotado em um container é possível gerar uma imagem e porta-la para qualquer outro ambiente com Docker instalado, ou iniciá-la de maneira rápida.

Um exemplo de uso no contexto de testes automatizados, seria Jenkins gerar um container Docker, através de scripts, a partir de uma imagem semelhante ao ambiente de produção, implantando o artefato gerado no estágio de commit. Então, os testes de aceitação automatizados serem executados e o container ser encerrado.

Com as ferramentas citadas é possível criar testes de aceitação satisfatórios para atender os requisitos do pipeline de implantação. Os estágios subsequentes não devem ser chamados automaticamente, caso este obtenha sucesso, pelo contrário, devem ser chamados manualmente de acordo com a necessidade. Jenkins permite esta execução manual com um clique de um botão e apresenta em seu dashboard todas as versões candidatas disponíveis e suas situações.

 

Estágio de Testes de Aceitação Manuais

 

Neste estágio são realizados testes exploratórios, de usabilidade e demonstrações que podem contar com a participação do cliente ou usuário. Para Humble e Farley (2014), o principal papel deste estágio é garantir que os testes de aceitação de fato validem o comportamento do sistema provando manualmente que os critérios de aceitação foram atendidos.

Pode-se utilizar da ferramenta Docker, já mencionada anteriormente, para criar o ambiente de homologação onde os testes manuais serão realizados. Também é importante que o ambiente de testes seja próximo ao de produção.

 

Estágio de Testes Não Funcionais

 

Este estágio visa medir quão bem o sistema atende aos requisitos não funcionais levantados. Não é um estágio obrigatório, devendo-se levar em consideração sistema a sistema.

Quando necessário, é importante desde o início do projeto ter em mente quais os impactos dos requisitos não funcionais na arquitetura, nos testes e nos custos gerais. Uma má análise pode levar a projetos exagerados ou que não suportem a carga em produção.

Como existem inúmeros testes não funcionais possíveis, para não fugir do escopo do trabalho, serão considerados capacidade, desempenho e stress, por serem úteis a maioria das aplicações.

O sucesso ou falha destes testes é mais baseado em medição humana que em um resultado binário. Por exemplo, uma alteração pode ter um alto impacto no desempenho da aplicação, mas ainda assim, ela ser aprovada no teste de desempenho. Sem uma análise tal alteração pode passar despercebida.

Uma ferramenta que deve ser considerada para testes não funcionais de capacidade, desempenho e stress é o JMeter, originado para testes de aplicações WEB. É bastante popular e considerado muito fácil de se usar, possuindo diversas configurações para aplicar testes simples e complexos, também permite a geração de relatórios gráficos intuitivos para exibição dos resultados. Possui integração com Jenkins.

No próximo e úlitmo post da série será mostrado o estágio de entrega em produção e a conclusão do que foi apresentado. Acesse aqui.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s