Testes de software automatizados

Por que a automação de testes é importante para a entrega contínua?

O foco da entrega contínua (CD) é entregar novos lançamentos de código o mais rápido possível para os clientes. O teste automatizado é fundamental para esse objetivo. Não há como automatizar a entrega aos usuários se houver uma etapa manual e demorada no processo de entrega.

A CD faz parte de um pipeline de implementação maior. A CD é sucessora e também dependente da integração contínua (CI). A CI é totalmente responsável por executar testes automatizados para quaisquer novas alterações de código e verificar se essas alterações não quebram recursos estabelecidos ou introduzem novos bugs. A CD é acionada quando a etapa de integração contínua passa no plano de teste automatizado.

Essa relação entre testes automatizados, CI e CD produz muitos benefícios para uma equipe de software de alta velocidade. Os testes automatizados garantem a qualidade em todas as fases do desenvolvimento, garantindo que os novos commits não introduzam nenhum bug, para que o software permaneça pronto para implementação a qualquer momento.

1. Testes de ponta a ponta

É possível afirmar que os testes com implementação mais valiosa são testes de ponta a ponta (E2E). Os testes E2E simulam uma experiência de nível de usuário em toda a pilha de um produto de software. Planos de testes E2E em geral abrangem histórias de nível de usuário como: “o usuário pode entrar”, “o usuário pode fazer um depósito” ou “o usuário pode alterar as configurações de e-mail”. A implementação desses testes é muito valiosa, pois eles oferecem garantia de que os usuários reais estão tendo uma experiência sem bugs, mesmo quando novos commits são enviados.

As ferramentas de teste E2E capturam e reproduzem ações do usuário, de modo que os planos de teste E2E passam a ser gravações dos principais fluxos de experiência do usuário. Se em um produto de software estiver faltando qualquer tipo de abrangência de testes automatizados, ele vai obter o máximo valor implementando testes E2E dos fluxos de negócios mais críticos. Os testes E2E podem ser caros no início para capturar e gravar a sequência de fluxo do usuário. Se o produto de software não estiver fazendo lançamentos diários rápidos, pode ser mais econômico ter uma equipe humana para fazer a execução manual dos planos de teste E2E.

2. Testes de unidade

Como o nome indica, os testes de unidade abrangem unidades individuais de código. Unidades de código são melhor medidas em definições de função. Um teste de unidade abrange uma função individual. Os testes de unidade confirmam que a entrada esperada para uma função corresponde à saída esperada. No caso de código com cálculos sensíveis (como pode ser o caso de finanças, cuidados de saúde, ou aeroespacial) os testes de unidade são melhores. Os testes de unidade são baratos e rápidos de implementar e proporcionam um alto retorno sobre o investimento.

3. Testes de integração

Muitas vezes, uma unidade de código vai fazer uma chamada externa para um serviço de terceiros. A base de código principal que está sendo testada não vai ter acesso ao código deste utilitário de terceiros. Os testes de integração envolvem simular essas dependências de terceiros e confirmar que o código que tem interface com elas se comporta como esperado.

Os testes de integração são semelhantes aos testes de unidade na forma como são escritos e em relação às ferramentas. Os testes de integração podem ser uma alternativa barata aos testes E2E, mas o retorno sobre o investimento é discutível quando a combinação de testes de unidade e E2E já é utilizada.

4. Testes de desempenho

Quando usado no contexto do desenvolvimento de software, o "desempenho" é usado para descrever a velocidade e a capacidade de resposta com que um projeto de software reage. Alguns exemplos de métricas de desempenho são: "tempo para carregamento da página", "tempo para a primeira renderização", "tempo de resposta dos resultados da pesquisa". Testes de desempenho criam medições e asserções para esses casos de exemplo. Testes de desempenho automatizados executam casos de teste em todas essas métricas e, em seguida, alertam a equipe para quaisquer regressões ou perda de velocidade.

Que tipos de testes de software devem ser feitos manualmente?

É discutível que quaisquer testes que possam ser automatizados devam ser automatizados. É um enorme ganho em produtividade e custo de tempo humano. Por outro lado, há momentos em que o ROI do desenvolvimento de um conjunto de testes automatizado não vale a pena quando comparado à execução de um teste manual.

1. Testes exploratórios

Os testes automatizados têm um script e seguem uma sequência de etapas para validar o comportamento. Os testes exploratórios são mais aleatórios e examinam sequências sem script para encontrar bugs ou comportamento inesperado. Embora existam ferramentas de software para estabelecer um conjunto de testes exploratórios de software, elas não são totalmente maduras e amplamente adotadas ainda. Pode ser muito mais eficiente atribuir um testador de garantia de qualidade manual e usar a criatividade humana para explorar como fazer um produto de software quebrar.

2. Testes de regressão visual

Uma regressão visual acontece quando uma falha de design visual é introduzida na interface do usuário do software. Essa falha que pode envolver elementos de interface do usuário mal posicionados, fonte errada, cores erradas ou outros casos. Tal como acontece com testes exploratórios, existem ferramentas para escrever testes automatizados para capturar essas regressões. Essas ferramentas fazem capturas de tela de vários estados de um produto de software e, em seguida, usam OCR para fazer a comparação com os resultados esperados. Desenvolver esses testes é caro, e a adoção das ferramentas não é ampla. Pode ser muito mais eficaz usar o olhar humano para ver se há algum problema visual.

3. Criação de estrutura de automação de testes para a equipe de DevOps

Não existe uma solução absoluta para testes automatizados. Ao planejar uma solução de teste automatizado para sua equipe, há algumas considerações importantes a serem feitas.

4. Frequência de lançamento

Produtos de software com lançamentos em intervalos fixos, como mensais ou semanais, podem ter no teste manual a melhor solução. Produtos de software com lançamentos mais rápidos vão ter muitos benefícios com os testes automatizados, uma vez que CI e CD dependem de testes automatizados.

5. Ferramentas e ecossistema disponíveis

Cada linguagem de programação tem seu próprio ecossistema de ferramentas e utilitários complementares. Cada tipo de padrão de teste automatizado tem seu próprio conjunto de ferramentas que podem ou não estar disponíveis em um ecossistema de linguagens de programação específico. A implementação bem-sucedida de um padrão de teste automatizado vai exigir uma interseção do suporte de linguagem e ferramenta.

6. Ajuste do mercado do produto e vencimento da base de código

Se sua equipe está trabalhando na construção de um novo produto que ainda não tenha provado um público-alvo ou modelo de negócios, pode não fazer sentido investir em testes automatizados. Os testes automatizados atuam como um mecanismo de seguro para restringir regressões inesperadas de código. Se sua equipe está se movendo em alta velocidade, a atualização e a manutenção de testes automatizados podem ficar caras e gerar frustração quando o código está passando por mudanças drásticas e rápidas.

Faça o teste automatizado da parte de seu pipeline de CD

O teste automatizado é uma prática moderna padrão de desenvolvimento de software. As melhores equipes e empresas usam testes automatizados. A CI/CD depende de testes automatizados e é essencial para ajudar as melhores equipes a lançar software confiável e robusto para seus clientes.

O Open DevOps da Atlassian oferece uma plataforma aberta de cadeia de ferramentas que permite gerar um pipeline de desenvolvimento baseado em CD (implementação contínua) com as ferramentas que você adora. Saiba como as ferramentas da Atlassian e de terceiros podem integrar testes no fluxo de trabalho com os tutoriais de teste de DevOps.