O que é o Shift Left Testing? E o que isso significa para DevOps?

A metodologia de teste shift left é uma abordagem para testes de software que traz os requisitos de teste mais cedo para o ciclo de desenvolvimento de software.

 

O desenvolvimento de software tem visto uma grande evolução nas últimas décadas. Hoje, engenheiros e testadores de desempenho podem integrar qualquer número de ferramentas de automação, aprendizado de máquina e IA em seus testes. Não foi há muito tempo quando o teste de software era uma nota lateral. Na verdade, o desenvolvimento precoce de software nem sequer teve uma fase formal de testes. A introdução dos testes não aconteceu até que o software se tornasse mais complexo, onde bugs e defeitos do ambiente de produção começaram a impactar os negócios. Os desenvolvedores realizaram os testes em si, não uma equipe separada. Foi assim que os testes funcionais surgiram e se tornaram parte do modelo tradicional de cachoeira, composto por etapas separadas (Análise, Requisitos, Design, Codificação, Testes, Aceitação, Produção e Pós-Produção) que se moviam por um caminho linear, semelhante a uma linha de montagem em uma fábrica.

Modelo de Cachoeira por Paul Hoadley. Usado sob a Licença Creative Commons.

 

Uma vez que cada etapa estava completa, passou para o grupo seguinte e desceu a linha. Parecia bom no papel, mas a QA não testou o código até que a maioria desses estágios estivesse completa. Consequentemente, isso significava que havia muito pouco tempo para fazer modificações no código antes da produção. Se o problema ou bug foi severo o suficiente, isso significava desmantelar ou atrasar o projeto. Além disso, isso significou uma perda potencial para as empresas, dependendo da importância do aplicativo de software.

 

Teste à esquerda de turno – Estabelecendo a Fundação

Felizmente, as lições dispendiosas aprendidas com erros de desenvolvimento anteriores ajudaram a introduzir o método de mudança para a esquerda. As organizações perceberam que identificar problemas no final do jogo não era apenas muito caro, mas também arriscado. Um artigo do TechRepublic de maio de 2019 informou que o custo médio anual para corrigir bugs visuais em software é de mais de US$ 400.000. Não é exatamente uma mudança.

Além disso, a indústria como um todo estava mudando. Houve uma transformação digital com a que as empresas tiveram que enfrentar. As organizações estavam começando a perceber que não podiam mais confiar em ciclos de lançamento de um a dois por ano. As expectativas e demandas dos clientes eram altas. Lançar um produto mal projetado significava perder clientes para a concorrência. Algo tinha que mudar.

As organizações começaram a dividir o ciclo de desenvolvimento em blocos menores e gerenciáveis e incorporar testes em cada fase. Isso permitiu um ambiente mais colaborativo, dando às equipes a capacidade de identificar problemas mais cedo. Por exemplo, ao entender melhor os requisitos de software no início do processo, as equipes de teste poderiam ajudar a desenvolver melhores casos de teste para corrigir quaisquer bugs potenciais. Isso também é conhecido como “falhar cedo e muitas vezes” ou “falhar rápido”. A consideração pelos cenários do usuário e pelo comportamento do software no início do processo elimina possíveis bugs e otimiza o código. Isso permite que as equipes entreguem um produto consistente.

Obviamente, haverá momentos em que os testes não fazem sentido. Por exemplo, você não pode realizar testes de GUI até que você tenha uma GUI. No entanto, a mudança à esquerda é mais uma mentalidade, não apenas um processo de desenvolvimento. Mais importante ainda, as equipes devem estar sempre pensando no que tornaria uma melhor experiência do usuário. Em última análise, é o usuário que vai ter o produto final em suas mãos. Qualquer coisa que possa melhorar uma aplicação antes de ser empurrada para a produção beneficia a todos.

 

O aumento dos testes à esquerda do turno e os ágeis e devops

Devido ao aumento dos avanços tecnológicos e foco na experiência digital, ocorreu uma mudança de paradigma. Os ciclos de desenvolvimento e teste tornaram-se mais curtos e mais frequentes. Isso resultou em novos recursos sendo trazidos ao mercado mais cedo. O mais importante, não só isso permitiu que as empresas se mantivessem competitivas, como mantinha os clientes felizes e engajados. Por exemplo, aplicativos móveis e web normalmente funcionam dentro de ciclos de lançamento de duas semanas. Algumas organizações liberam atualizações diárias – ou até mesmo de hora em hora!

O foco para o desenvolvimento de aplicativos e softwares é ser rápido, ágil e reduzir o risco. As organizações estão enfrentando esse desafio por meio de práticas ágeis de desenvolvimento de software e DevOps. O desenvolvimento ágil de software é semelhante ao modelo waterfall; no entanto, a principal diferença é que em um modelo de cachoeira, há sempre uma fase de teste após a fase de projeto. O método Ágil divide o desenvolvimento em pequenas iterações, chamadas sprints, que não duram mais quatro semanas. Cada sprint envolve membros da equipe multifuncional trabalhando em todos os aspectos do sprint, com testes concluídos em cada iteração. Isso permite mais colaboração entre os membros da equipe, ciclos de feedback mais curtos e um produto de maior qualidade.

E esse é outro fator importante sobre o teste de mudança à esquerda. Nos testes tradicionais de cachoeira, a responsabilidade por testar e gerenciar a qualidade do produto recai sobre a equipe de QA. Em shift left testing e ambientes ágeis, desenvolvedores e testadores realizam os testes reais, mas a responsabilidade acaba recaindo sobre todos por causa de sua abordagem colaborativa e multifuncional durante o desenvolvimento. Hoje, existem quatro abordagens diferentes para mudar os testes à esquerda: testes tradicionais, incrementais, ágeis/devOps e de turno baseados em modelos.

 

Tipos de teste à esquerda de turno

Nos últimos anos, o termo DevOps tornou-se mais uma palavra de ordem para marketing, produtos de software e até descrições de trabalho. Simplificando, o DevOps é uma estrutura alternativa dentro da abordagem Ágil que visa reunir equipes de Desenvolvimento e Operações. Historicamente, cada departamento tinha seus respectivos objetivos, por vezes contraditórios. Os desenvolvedores criam, projetam e inovam. As equipes de operações se concentram na infraestrutura e em “manter as luzes acesas” com monitoramento contínuo para garantir a disponibilidade. Da mesma forma, o DevOps foi criado especificamente para trazer mais colaboração, feedback e agilidade entre esses departamentos. DevOps também é referido quando se fala em CI/CD (Continuous Integration and Continuous Deployment) e automação, mas o fato de uma organização usar CI/CD e automação, não os torna automaticamente certificados em DevOps.

 

Teste de carga práticas recomendadas para ambientes devops

Se suas equipes seguirem uma abordagem desatualizada de teste de carga e monitoramento, o DevOps poderá levá-lo rapidamente a um desastre de desempenho. As equipes de QA têm que lidar com implantações frequentes de lançamento. As equipes do DevOps precisam de uma maneira fácil de gerenciar seus testes, além de um monitoramento flexível, para fornecer insights adequados.

Teste contínuo de carga.

Há muitas alterações que podem afetar a interface do usuário e travar o teste de carga. O foco inicial deve ser executar testes de API totalmente automatizados e programá-lo para execução diária. Uma vez que os principais processos de negócios estejam estáveis, você pode adicionar testes adicionais de ponta a ponta ao seu cenário de teste

Compartilhe informações valiosas.

Envolva sua equipe de DevOps em atividades de análise de resultados. Não pratique informações se escondendo. Compartilhe todos os testes de carga (incluindo testes de carga Selenium) e os resultados de monitoramento com seus engenheiros para descobrir a causa de todos os problemas.

Monitoramento de todas as camadas.

A mudança à esquerda também significa ter um monitoramento semelhante à produção em estágios de Desenvolvimento e QA. Você não terá tempo para reproduzir continuamente erros em pipelines de desenvolvimento ágeis. Certifique-se de coletar métricas de uso de front-end, back-end e infraestrutura 24 horas por dia, 7 horas por dia, 7º períodos de produção.

Linha de base e benchmark.

Testes contínuos de carga produzem toneladas de dados. Defina linhas de base e use benchmarks para detectar desvios no início do ciclo. Quanto mais cedo você souber sobre lentidão, mais tempo sua equipe de Desenvolvimento terá para corrigir tais problemas.

 

Integrando testes de desempenho na metodologia Shift Left

Os aplicativos atuais utilizam múltiplas tecnologias, contando com vastas redes de provedores de terceiros e CDN’s. Some-se ao fato de que os usuários podem acessar seus aplicativos de qualquer lugar do mundo, de qualquer número de dispositivos, todos com velocidades de conexão variadas. Isso é muito para explicar ao tentar dar aos usuários uma ótima experiência o tempo todo. Tempos de resposta, qualidade e disponibilidade são fatores críticos que precisam de atenção antes de empurrar os aplicativos para a produção.

Uma vez em produção, seu aplicativo ou site precisará suportar centenas, ou até milhares de usuários simultâneos. Pequenas alterações incrementais no código podem afetar o desempenho, de modo que quanto mais cedo você puder encontrar bugs relacionados ao desempenho, mais fácil e menos caro será corrigi-los. Na maioria dos casos, as equipes devem ser capazes de corrigir quaisquer problemas de desempenho dentro de um ou dois dias. Mais uma vez, é muito mais fácil realizar essas melhorias então, em vez de descobri-las antes da implantação.

Idealmente, uma vez que o código tenha passado pelos testes funcionais necessários, com recursos examinados e assinados, as equipes devem executar testes não funcionais, como testes de estresse e carga, para ver o quão bem os artefatos de teste funcionais resistem aos usuários virtuais. O LoadView desempenha uma parte integral da abordagem de teste de deslocamento para a esquerda, permitindo que os usuários ganhem tempo, dinheiro e forneçam código e aplicativos otimizados.

 

A plataforma LoadView: Testes de carga baseados em nuvem em navegadores reais

A plataforma LoadView é uma plataforma flexível de teste de carga que pode resolver o problema de padrões de carga ineficazes, simulando tudo, desde testes baseados em protocolos até testes reais baseados em navegador. Ele é totalmente baseado em nuvem, portanto, não há necessidade de configurar e implantar injetores de carga internos, gerenciar contas de nuvem de terceiros ou se preocupar com requisitos de hardware ou software. O teste de desempenho geralmente requer infraestrutura e recursos adicionais que algumas organizações podem não ser capazes de suportar. O LoadView gerencia isso para você através da plataforma.

O LoadView é ideal para testar código ou serviços da Web antecipadamente para ajudar a avaliar as características de desempenho, pois pode facilmente girar e simular altos níveis de carga no back-end a partir de um único injetor de carga, economizando tempo e dinheiro em comparação com outras ferramentas. Isso o torna ideal para testar arquiteturas de API da Web como JSON, SOAP e REST. Além disso, testes não funcionais normalmente exigem tempos de configuração mais longos e scripts complexos que exigem que os desenvolvedores e engenheiros tenham conhecimento prático de linguagens de programação específicas. Isso às vezes pode ser difícil de automatizar, pois eles tendem a funcionar apenas em um ecossistema específico de fornecedores. Este não é o caso do LoadView.

 

Scripting Facilitado: O gravador web EveryStep

O LoadView utiliza um gravador de scripts fácil de usar chamado EveryStep Web Recorder. Os usuários podem facilmente criar ações avançadas de scripting que simulam ações reais do usuário com suas APIs, aplicativos web e sites. Para validar os tempos de resposta de ponta a ponta para aplicativos do lado do cliente, os usuários podem simplesmente navegar através de seu caso de teste e registrar cada ação. Entender a quantidade de carga que uma API ou aplicativo web pode lidar durante a fase inicial de desenvolvimento pode ajudar os desenvolvedores nessas áreas críticas:

• Determinando as linhas de base do tempo de resposta em números específicos de carga do usuário
• Identificação de gargalos de desempenho
• Encontrar limites superiores de seus sistemas atuais para planejamento de capacidade
• Analisando o desempenho do servidor (CPU, memória, largura de banda, I/O do disco) e os tempos de resposta do banco de dados

O gravador também suporta mais de 40 navegadores e dispositivos populares para desktop/mobile, bem como tecnologias web e linguagens de programação, como AJAX, HTML5, JavaScript, Flash, Silverlight e muito mais. O LoadView utiliza esses scripts para executar testes de estresse e carga sob demanda, de mais de 13 locais globais (Estados Unidos, Canadá, América do Sul, Europa e APAC), fornecendo aos engenheiros de testes dados de desempenho do mundo real de navegadores reais. Lembre-se, executar um teste interno pode dizer o quão bem seu aplicativo ou site lida com um aumento no tráfego de dentro de sua própria rede, mas nunca refletirá as condições do mundo real. Aplicativos e sites que não são devidamente testados e otimizados podem impactar negativamente as conversões e, em última instância, a receita.

 

LoadView: Flexibilidade para testar cenários do mundo real

O LoadView oferece aos usuários a opção de distribuir a carga do usuário entre locais geográficos com base na porcentagem de tráfego para seu site. Por exemplo, se você sabe que uma certa porcentagem de seus clientes e usuários vem de uma localização geográfica específica, você pode selecionar essas áreas específicas para testar. A plataforma utiliza os Serviços Web da Amazon (AWS) e o Azure Cloud Services para gerar usuários virtuais. Além disso, os usuários podem levar seus testes de carga um passo adiante, personalizando o tipo de curva de carga. Isso proporciona uma flexibilidade ainda maior para os engenheiros de teste, dependendo de seu cenário único. Os usuários do LoadView podem escolher entre três curvas de carga diferentes:

Curva de passo de carga

• • Começa com um número pré-determinado de usuários simultâneos e aumenta gradualmente a carga para ver como seu site pode lidar com um pico de tráfego e compará-lo com o tráfego esperado.

Curva baseada em metas

• • Este tipo de curva de carga é útil quando você já determinou sua meta de throughput ou número de visitantes ao seu site durante um intervalo de tempo fixo. Ótimo para validar requisitos SLA ou não funcionais.

Curva ajustável dinâmica

• • Este teste permite que os usuários ajustem a carga enquanto o teste está sendo executado para descobrir os limites de desempenho de sites ou capacidade do servidor.

Após o término dos testes, o LoadView gera automaticamente relatórios que auxiliam as equipes na medição do sucesso de seus KPIs (Key Performance Indicators), como número de usuários simultâneos, erros, tempos médios de resposta, uso de CPU, throughput, latência e muito mais. Essas métricas são fundamentais para desenvolvedores, DevOps e equipes de QA, pois ajudam a descobrir gargalos do mundo real que poderiam afetar potencialmente o desempenho do usuário final.

 

Depois de mudar para a esquerda, não se esqueça de mudar para a direita

Com todo o foco nos testes de turno esquerdo, é difícil lembrar que há outro passo extremamente importante no processo que recebe menos atenção. Depois que seu aplicativo entra em produção, você tem que garantir que tudo continue funcionando sem problemas para os usuários. O Dotcom-Monitor oferece várias soluções de monitoramento para garantir que suas páginas e aplicativos continuem a funcionar e funcionar corretamente.

Monitoramento de serviços web

• • Tempo de atividade e desempenho de serviços web, como HTTP/S, SOAP/REST e muito mais

Monitoramento de páginas da Web

• • Desempenho de páginas da Web em navegadores reais, identificando elementos mais lentos e rápidos ao longo do tempo

Monitoramentode aplicativos web

• • Monitore aplicações web complexas, como AJAX, PHP, Ruby, Flash e muito mais

Monitoramento de infraestrutura

• • Funcionalidade e desempenho de servidores e protocolos de Internet, como HTTP/S, e-mail, mídia de streaming, VoIP e muito mais

Essas plataformas permitem que os usuários configurem um monitoramento contínuo com base em limites personalizados e podem alertar indivíduos ou equipes específicas quando ocorrem erros para que possam trabalhar na correção de problemas antes de potencialmente impactar muito mais usuários.

 

Teste à esquerda de turno: bom para os negócios e paz de espírito

Em conclusão, tanto os conceitos de esquerda e de mudança podem ser extremamente valiosos, não apenas dentro do ciclo de desenvolvimento de software, mas também dentro de outros departamentos e indústrias. Por exemplo, os gerentes de produto ou os gerentes de experiência do cliente estão ‘mudando à esquerda’ e estão se tornando mais frequentemente engajados com clientes reais para obter feedback contínuo. Isso permite que as organizações se tornem mais ágeis e se aproximem da fonte de informação e feedback para entender melhor seus clientes. Pense nisso. Você não teria mais chances de trabalhar com alguém, ou continuar a fazer negócios com uma empresa que valoriza sua entrada? Então, agora, quando você ouve alguém dizer, “mudar para a esquerda” ou “testar cedo e muitas vezes”, não é apenas um buzzword chique que eles estão jogando ao redor. É uma peça crítica do quebra-cabeça da experiência do cliente e que você deve sempre manter no fundo de sua mente. Não só seus usuários e clientes ficarão felizes, como ganharão eficiências, alcançarão melhores resultados e darão tranquilidade a você e à sua organização.