O Guia Definitivo de
Testes Contínuos

03. Ambientes e Infraestrutura¶

Presumivelmente, algo com que todos podem concordar é que existem pelo menos três ambientes diferentes para se trabalhar: um para desenvolvimento, onde o código é compilado e testado localmente a cada modificação, um para os testadores testarem as versões "fechadas" que estão prontas para testar, e o ambiente de produção, onde se encontra o código do sistema que os usuários enfrentam.

Nunca ocorre a ninguém ir do ambiente de desenvolvimento direto para o ambiente de produção, certo? Porque isso seria pura loucura…

Infelizmente, algumas equipes fazem exatamente isso, rodam testes no ambiente errado. Há muitas que não têm nem os três ambientes básicos para realizar essas práticas, o que causa muitas consequências. Por exemplo, é aí que se pode ouvir a desculpa dos desenvolvedores: "Bom, funciona no meu computador", quando algo não está funcionando para o usuário (quando mais importa).

Para realmente testar o software antes que ele chegue ao usuário, é essencial ter um ambiente específico para isso e, às vezes, nem isso é suficiente. Especialmente para as verificações automatizadas, é essencial rodar esses testes com os dados para eles em isolamento.

Além disso, é aconselhável ter um ambiente separado para garantir que eles não serão modificados (se forem modificados, há o risco de obter falsos positivos).

É fundamental gerenciar bem o ambiente de testes, considerando muitos de seus diferentes elementos:

• Os arquivos-fonte e os executáveis da aplicação
• Os dispositivos de teste e os dados que eles usam
• Por sua vez, os dados estão relacionados ao sistema de banco de dados em cada ambiente, então é necessário gerenciar o esquema e os dados do banco de dados correspondente

Se houver diferentes testes a serem realizados com diferentes configurações, parametrizações etc., será necessário mais de um ambiente de testes, ou um ambiente e muitos backups de banco de dados, um para cada conjunto de testes. Isso significa que é preciso realizar uma manutenção específica para cada backup (por exemplo, sempre que houver mudanças no sistema em que o banco de dados é modificado, deve-se aplicar essas mudanças a cada backup).

Mas se um desses elementos não estiver em sintonia com o restante, os testes provavelmente falharão e levarão à ineficiência. É crucial ter certeza de que cada vez que um teste reporta um erro, é porque realmente há um bug em vez de produzir um alarme falso.

Para resolver todos esses problemas no nível do ambiente, normalmente há papéis especiais dentro de uma equipe. Uma tendência do setor imensamente popular agora é ter DevOps. Há uma leve controvérsia sobre o termo, porque o conceito original estava relacionado à cultura de uma equipe, e não designado a papéis individuais. Mas, hoje, você verá empresas contratando um "Engenheiro de DevOps". De acordo com a Puppet Labs, as equipes que empregam DevOps entregam 30 vezes mais frequentemente, têm 60 vezes menos falhas e se recuperam 160 vezes mais rápido.

Basicamente, o papel do DevOps é combinar a visão da gestão de operações (infraestrutura e ambiente), do desenvolvimento e do negócio. Conectar essas áreas torna possível resolver de forma rápida e eficiente todas as necessidades da equipe, ao mesmo tempo em que coloca o foco no cliente e no usuário final.

Quanto às ferramentas, o DevOps normalmente aproveita as facilidades das máquinas virtuais, bem como outras mais avançadas como o Docker e o Kubernetes. Quando se trata da variedade de dispositivos mobile necessários para os testes, existem várias soluções para evitar comprar e manter dezenas de dispositivos todos os meses, desde laboratórios de dispositivos até soluções compartilhadas na nuvem que oferecem acesso a dispositivos em regime de pagamento conforme o uso.

Assim, ter múltiplos ambientes devidamente gerenciados ajuda a evitar perguntas como: "Temos certeza de que estamos testando na versão mais recente?" Também é fundamental ter todos os ambientes de que os testadores precisam, o que pode incluir fornecer acesso a diferentes sistemas operacionais com diferentes configurações, diferentes versões de navegador, ou até mesmo ter acesso a vários dispositivos mobile. Devido à vasta gama de dispositivos no mercado e à fragmentação dentro do Android e, hoje em dia, até do iOS, é necessário testar no maior número possível dos dispositivos mais relevantes.

No que diz respeito à cobertura de dispositivos mobile, uma estratégia com a qual a Abstracta viu ótimos resultados é a "cobertura cruzada ao longo do tempo". Enquanto testar em uma variedade de dispositivos exige mais tempo de execução, a estratégia de cobertura cruzada visa melhorar a cobertura ao longo do tempo. Essa estratégia simplesmente propõe organizar as execuções de tal forma que elas não sejam todas rodadas em cada ciclo de execução, mas sim rodadas de forma alternada, melhorando a cobertura após muitos ciclos. As imagens a seguir exemplificam essa estratégia:

Após o quê, no terceiro ciclo de execução, a cobertura total é alcançada:

Isso não garante 100% de cobertura em cada execução, mas, ao conseguir alternar as execuções de teste, uma maior cobertura é sucessivamente alcançada.

Essa mesma estratégia se aplica a navegadores web, parâmetros ou muitas outras variáveis com as quais os testadores têm de "brincar".

Para alcançar a maturidade em testes, são necessários os ambientes indispensáveis para a execução dos testes, a fim de garantir que não haja problemas adicionais além daqueles que se espera revelar por meio dos testes.