Tipos de testes utilizados em DevOps

Muitos projetos dependem unicamente de testes de aceitação manuais para verificar se um pedaço de software está de acordo com seus requisitos funcionais e não funcionais. Mesmo onde existam testes automatizados, eles são frequentemente mal mantidos e desatualizados e requerem complementação com testes manuais extensivos.

O teste é uma atividade multifuncional que envolve toda a equipe, e deve ser feito continuamente desde o início do projeto. Construir qualidade significa criar testes automatizados em vários níveis (unidade, componente e aceitação) e executá-los como parte do pipeline de implantação, que é acionado toda vez que uma alteração é feita no aplicativo, na configuração ou no ambiente e na pilha de software que é executado.

Existem muitos tipos de testes que são amplamente utilizados para modelar os vários tipos de testes que devem ser usa- dos para garantir a entrega de uma aplicação de alta qualidade.

Neste diagrama, há testes voltados para o negócio ou voltados para a tecnologia, e aqueles que suportam o processo de desenvolvimento ou são utilizados para criticar o projeto.

Os testes nesse quadrante são mais conhecidos como testes funcionais ou de aceitação. Testes de aceitação garantem que os critérios de aceitação de uma história sejam satisfeitos. Eles devem ser escritos, e preferencialmente automatizados, antes do início do desenvolvimento de uma história. Testes de aceitação, como os critérios de aceitação, podem testar todos os tipos de atributos do sistema que está sendo construído, incluindo funcionalidade, capacidade, usabilidade, segurança, fácil modificação, disponibilidade, e assim por diante. Testes de aceitação responsáveis pela funcionalidade do sistema são conhecidos como testes de aceitação funcional – testes de aceitação não funcional pertencem ao quarto quadrante do diagrama.

Testes de aceitação são fundamentais num ambiente de desenvolvimento ágil, pois respondem às questões “Como sei que terminei?”, para os desenvolvedores, e “Consegui o que queria?”, para os usuários. Quando os testes de aceitação obtêm sucesso, quaisquer que sejam os requisitos ou histórias que eles testam podem ser considerados completos. Então, num mundo ideal, clientes e desenvolvedores irão escrever testes de aceitação, já́ que eles definem o critério de sucesso para cada requisito. Ferramentas modernas de testes automatizados, como Cucumber, JBehave, Concordion, e Twist, visam realizar este ideal separando os scripts de testes de sua implementação, enquanto fornecem um mecanismo que simplifica a sincronização entre ambos. Dessa maneira, os usuários podem escrever os scripts de testes, enquanto os desenvolvedores e testadores trabalham juntos no código que os implementa.

Em geral, para cada história ou requisito existe apenas um caminho aprovado dentro da aplicação no que diz respeito às ações executadas pelo usuário. Isso é conhecido como caminho esperado.

No entanto, qualquer uso, em qualquer sistema, exceto os mais simples, permitirá variações de seu estado inicial, de ações executadas e do estado final da aplicação. Por vezes, essas variações formam casos distintos de uso, que são conhecidos como caminhos alternativos. Em outros casos, eles deverão causar condições de erro, resultando no que é chamado de caminhos não esperados. Obviamente existem muitos testes possíveis, que podem ser executados com diferentes valores para estas variáveis. Análise de particionamento de equivalência e análise de valor limite irão reduzir essas possibilidades para um conjunto menor de casos que testarão completamente o requisito em questão. No entanto, você̂ ainda deverá utilizar sua intuição para escolher os casos mais relevantes.

Testes de aceitação devem ser executados quando seu sistema se encontra em um modo similar ao de produção. Testes de aceitação manuais normalmente são feitos colocando-se a aplicação num ambiente de homologação (UAT**), que deve ser, o mais semelhante possível ao da produção em sua configuração e em termos do estado da aplicação – no entanto, pode utilizar versões mock de serviços externos. O testador utiliza a interface padrão da aplicação para testá-la. Da mesma forma, testes de aceitação automatizados devem executar em um ambiente parecido ao da produção, em que os testes interagem com a aplicação da mesma forma que um usuário faria.

Estes testes manuais verificam se a aplicação irá de fato entregar aos usuários o valor que eles esperam. Não se trata somente de verificar se a aplicação está de acordo com as especificações, mas de verificar se as especificações estão corretas.

Inevitavelmente, quando os usuários passam a utilizar a aplicação no cotidiano, eles descobrem que há espaço para melhorias. Eles quebram a aplicação porque executam conjuntos de operações que não foram tentadas antes. Eles reclamam que a aplicação poderia ajudá-los melhor com as tarefas que eles executam com mais frequência. Talvez eles sejam inspirados pela aplicação e identificam novas funcionalidades que irão agregar ainda mais valor a ela. Desenvolvimento de software é naturalmente um processo interativo que desenvolve o estabelecimento de feedback eficiente; estaríamos nos enganando se víssemos de outra forma.

Um tipo particularmente importante de testes voltados ao negócio e que criticam o projeto são as demonstrações. Times ágeis fazem demonstrações aos usuários ao final de cada iteração para demonstrar as novas funcionalidades que foram entregues. Funcionalidades também devem ser demonstradas aos clientes sempre que possível durante o desenvolvimento, de forma a garantir que quaisquer mal-entendidos ou problemas nas especificações sejam identificados logo. Demonstrações bem-sucedidas podem ser uma bênção ou uma maldição – usuários adoram brincar com novidades. Mas com certeza eles terão várias sugestões de melhorias.

Nesse ponto, o cliente e o time do projeto deverão decidir o quanto desejam modificar seu plano para incorporar essas sugestões. Independentemente do resultado, é muito melhor receber o feedback mais cedo do que ao final do projeto, quando é muito tarde para fazer mudanças. As demonstrações são o centro de qualquer projeto: é o primeiro momento em que você pode realmente dizer que parte do trabalho está pronta de acordo com a satisfação das pessoas que, afinal, estão pagando por ele.

Finalmente, você pode disponibilizar sua aplicação para os usuários reais por meio de programas beta. De fato, muitos sites parecem estar em eterno estado beta. Alguns sites modernos (NetFlix, por exemplo) liberam continuamente novas funcionalidades para usuários selecionados sem que eles percebam.

Muitas organizações utilizam implantação canário, em que versões sutilmente diferentes da aplicação estão em produção ao mesmo tempo e sua eficácia é comparada. Essas organizações coletam estatísticas de como a nova funcionalidade está sendo usada e a eliminam se não estiver entregando valor suficiente. Isso oferece uma abordagem evolutiva muito eficaz para a adoção de novas funcionalidades.

Testes de aceitação têm duas categorias: testes funcionais e não funcionais. Falaremos do segundo.

Os testes utilizados para verificar se esses critérios de aceitação foram satisfeitos, e as ferramentas para executar esses testes, tendem a ser bastante diferentes daqueles utilizados para verificar a conformidade de critérios de aceitação funcionais. A preparação e a implementação desses testes frequentemente exigem recursos consideráveis, como ambientes especiais e conhecimento específico, e sua execução leva muito tempo (automatizados ou não). Portanto, sua implementação tende a ser adiada. Mesmo quando totalmente automatizados, eles em geral são executados com menos frequência e mais tarde no pipeline de implantação do que os testes funcionais de aceitação.

No entanto, as coisas estão mudando. As ferramentas utilizadas para a execução desses testes estão evoluindo, e as técnicas utilizadas para desenvolvê-los estão ficando mais em evidência. Fomos surpreendidos várias vezes por um desempenho ruim logo antes do lançamento, e recomendamos que você prepare pelo menos alguns testes não funcionais simples no início de qualquer projeto, não importando o quão simples ou inconsequente. Para projetos mais complexos e críticos, você deveria designar alocar tempo de projeto para pesquisa e implementação de testes não funcionais no início.

Sua organização precisa realizar uma transição na estratégia de teste para devops? Nós podemos ajudar com a nossa consultoria devops! Entre em contato conosco e conheça mais sobre a nossa consultoria.