O que é o teste shift-left?

Você já participou de um projeto de software que estourou o orçamento e ultrapassou todos os prazos? Já participou, sim. Todos nós já. Na verdade, se nunca passou por isso, você é um unicórnio e eu gostaria de ouvir sua história.

No início da minha carreira em desenvolvimento de software, aprendi a importância de planejar de trás para frente a partir de um prazo. Se um projeto tem um determinado prazo e os testes vão levar um determinado tempo, com essa informação podemos trabalhar de trás para frente e escolher uma data de entrega para o projeto. Perfeito, não é?

Bem, não exatamente. Embora reservar tempo para os testes manuais reduzisse parte do estresse nos últimos dias dos projetos, ainda havia surpresas demais.

Reservar tempo para os testes de QA é ótimo na teoria, mas desmorona rapidamente na prática assim que o primeiro bug ou defeito é identificado.

Quanto tempo vai levar para corrigir esse defeito? Qual será o impacto no cronograma? Novos bugs serão introduzidos? Como vamos garantir que cada correção seja verificada, com tempo para consertar o que quebramos enquanto corrigíamos a primeira coisa?

No fim das contas, nunca consegui encontrar a quantidade certa de tempo a alocar para o QA. Inevitavelmente, correções feitas às pressas eram mescladas no último minuto. Aprendi a manter minha agenda livre por algumas semanas após lançamentos importantes. Essa abordagem me permite fazer a triagem dos problemas que deixamos passar (ou introduzimos) em nossas corridas frenéticas rumo à linha de chegada.

O problema, no fim, não era o tempo disponível para os testes, mas sim o momento em que eles eram feitos. Eu precisava testar mais cedo e com mais frequência. Eu precisava de testes shift-left.

Se imaginarmos nosso processo de desenvolvimento de software como uma linha do tempo que corre da esquerda para a direita, o termo "teste shift-left" se explica por si só. Em termos simples, é a prática de testar as etapas iniciais, envolvendo os membros da equipe, incluindo testadores, desenvolvedores e stakeholders, na estratégia de testes. Além disso, envolve integrar os testes de recursos já existentes e novos com mais frequência ao longo do ciclo de vida de desenvolvimento.

O modelo V é uma forma útil de conceituar os ciclos de desenvolvimento de software. Se pegarmos o fluxo tradicional em cascata e "invertermos" o eixo Y na fase de implementação, obtemos o modelo V.

Um ciclo de desenvolvimento começa com requisitos de alto nível. Esses requisitos vão sendo refinados a cada passo sucessivo na descida do "V", até chegarmos à própria implementação em nível de código. Em seguida, verificamos a implementação, começando pelos testes de unidade mais granulares e subindo pelo "V" rumo aos testes de aceitação do usuário, mais abstratos.

Em um processo em cascata, o projeto inteiro é formado por um único "V". Como setor, aprendemos que, quando você deixa toda a validação para o fim de um projeto complexo, está basicamente se preparando para fracassar.

Em um processo iterativo, podemos pensar em cada sprint ou iteração como um "V" menor. Em teoria, alcançamos nossos objetivos de shift-left: testar mais cedo e com mais frequência. Problema resolvido, certo? Bem, não exatamente.

Talvez você tenha notado que há dois rótulos no canal de feedback integrado ao modelo V: verificação e validação. Ambos os rótulos são importantes.

Precisamos validar que nossos requisitos do usuário resolvem os problemas que nos propusemos a resolver. Também precisamos verificar que nossa implementação corresponde às especificações derivadas desses requisitos do usuário.

Os testes automatizados podem ser aplicados tanto a validações quanto a verificações. O projeto orientado por comportamento (BDD) levou à criação de tecnologias como o Cucumber, capazes de automatizar partes do processo de validação. Para os fins deste artigo, vamos nos concentrar nos testes automatizados voltados à verificação.

Os testes de unidade verificam a funcionalidade de um módulo específico dentro de uma aplicação maior. O módulo é testado de forma isolada, e qualquer comunicação com outros processos externos é simulada ou criada. Os testes de unidade e o TDD representam a primeira fase de desenvolvimento no teste shift-left.

Os testes de integração tentam verificar a funcionalidade geral de um serviço ou aplicação, incluindo efeitos colaterais. Esse processo é um antipadrão por motivos que discutiremos mais adiante.

Os testes de API verificam os endpoints externos de um único serviço. O escopo dos testes de API é semelhante ao dos testes de integração; no entanto, em um contexto de SOA ou de microsserviços, podemos pensar nos testes de API como os novos testes de unidade.

Os testes de IU verificam a funcionalidade completa de uma aplicação a partir da camada de interface do usuário. Ferramentas como o Selenium tornam os testes de IU automatizados amplamente acessíveis.

O shift-left não se resume à automação. Outra forma de testar mais cedo e com mais frequência é garantir que seus especialistas em QA participem de cada etapa do processo, a começar pela descoberta e pelo levantamento de requisitos. Os engenheiros de teste trabalham melhor quando têm uma compreensão maior da implementação como um todo, e seus insights podem ajudar a tornar a arquitetura mais aberta e resiliente.

Quando pensamos em testar "mais cedo e com mais frequência", uma palavra vem à mente: contínuo. Muitas (a maioria das) equipes de desenvolvimento de software praticam alguma forma de integração contínua e entrega contínua. Os testes contínuos são um ciclo de feedback essencial nesse ciclo de DevOps.

Se pensarmos no TDD como "shift-left para monólitos", então os testes contínuos são "shift-left para arquiteturas distribuídas".

O TDD nos fazia focar nos testes de unidade. Nos testes contínuos, devemos nos concentrar em testes de API e de contrato. Os testes de API têm algumas vantagens:

• Os testes de API podem evitar uma das formas mais comuns de introduzir erros em uma aplicação de microsserviços: alterar uma dependência em descompasso com seus serviços anteriores ou posteriores.
  

• Os testes de API podem ficar sob a responsabilidade da mesma equipe responsável pelo serviço.
  

• Os testes de API evitam a fragilidade de testar efeitos colaterais e detalhes de implementação.

O ideal é que esses testes de API sejam executados continuamente tanto em ambientes de produção quanto de pré-produção. As ferramentas de teste de contrato podem ajudar a automatizar esse processo, mas isso exige mais infraestrutura.

E se pudéssemos usar testes de API contínuos integrados à nossa ferramenta de observabilidade? O futuro recurso de testes sintéticos de API da Instana permitirá que você execute testes de API continuamente em todos os seus ambientes com esforço mínimo.

O shift-left envolve aproximar as atividades de teste do início do ciclo de vida de desenvolvimento de software, possibilitando um feedback mais rápido e reduzindo o tempo e o esforço necessários para a correção de bugs. Veja algumas boas práticas para o teste shift-left no desenvolvimento ágil:

1. Envolvimento antecipado: as atividades de teste devem começar o mais cedo possível no processo de desenvolvimento. Os testadores devem ser envolvidos desde a fase de levantamento de requisitos, para compreender o escopo do projeto, os objetivos e as expectativas dos usuários.
   

2. Colaboração e comunicação: promova uma colaboração e comunicação estreitas entre desenvolvedores, testadores e demais stakeholders. Incentive reuniões diárias de stand-up, sessões de planejamento de sprint e retrospectivas regulares para garantir entendimento e alinhamento compartilhados.
   

3. Automação de testes: invista em automação de testes para viabilizar testes frequentes e eficientes. Os testes automatizados devem ser criados em paralelo ao processo de desenvolvimento e integrados aos pipelines de integração e implementação contínuas. Isso ajuda a detectar defeitos cedo, reduzir problemas de regressão e acelerar os ciclos de feedback.
   

4. Desenvolvimento orientado por testes (TDD): incentive a prática do TDD, em que os desenvolvedores escrevem os casos de teste antes de escrever o código de fato. Essa abordagem de teste shift-left ajuda a definir o comportamento desejado e os resultados esperados desde o início, levando a um código mais sólido e testável.
   

5. Integração contínua e entrega contínua (CI/CD): implemente pipelines de CI/CD para automatizar os processos de desenvolvimento, teste e implementação. Essa prática garante que cada mudança de código seja minuciosamente testada e implementada nos ambientes de produção com rapidez e frequência, reduzindo o risco de problemas de integração.
   

6. Shift-left em testes de segurança: considere integrar práticas de testes de segurança no início do processo de desenvolvimento. Realize revisões de código voltadas à segurança, análise estática de código e testes com foco em segurança para identificar vulnerabilidades e tratá-las de forma proativa.
   

7. Testes exploratórios: além dos testes automatizados, incentive os testes exploratórios para explorar a aplicação sob a perspectiva do usuário. Testadores experientes conseguem identificar possíveis problemas de usabilidade, casos extremos e cenários que os testes automatizados podem deixar passar.
   

8. Testes de desempenho: faça testes de desempenho cedo para identificar possíveis gargalos e problemas de escalabilidade. Isso ajuda a otimizar o desempenho da aplicação e a garantir que ela atenda aos critérios de desempenho exigidos.
   

9. Ambientes e dados de teste: provisione ambientes de teste que se assemelhem bastante aos ambientes de produção para garantir testes de software realistas. Além disso, garanta que haja dados de teste suficientes e representativos para simular cenários do mundo real.
   

10. Aprendizado e melhoria contínuos: cultive uma cultura de aprendizado e melhoria contínuos. Incentive retrospectivas regulares para refletir sobre os processos de teste, identificar gargalos e implementar mudanças que aumentem a eficácia do teste shift-left.

Ao adotar essas boas práticas, as equipes ágeis conseguem obter melhor colaboração, feedback mais rápido e produtos de software de maior qualidade por meio do teste shift-left.

Os ciclos de feedback mais curtos integrados aos processos de shift-left nos beneficiam de várias maneiras. Para citar algumas: os defeitos podem ser encontrados mais rápido, as correções podem ser aplicadas com mais eficiência e as lições aprendidas em uma iteração podem ser aplicadas na seguinte.

Seja qual for a metodologia de gestão de projetos ou a cadência de lançamentos da sua equipe, você pode se beneficiar dos ciclos de feedback de verificação mais curtos que o teste shift-left proporciona.

Um defeito encontrado por um teste de unidade automatizado na máquina local de um desenvolvedor custa menos para ser identificado e corrigido. Mas quando um defeito chega ao ambiente do cliente, o custo para correções aumenta.

Quando bem feitos, os testes automatizados e a CI podem dar aos engenheiros de software a confiança de que precisam para implementar com frequência, até mesmo nas sextas-feiras. Encontrar defeitos mais cedo significa menos momentos de pânico que mobilizam a equipe inteira. Como os lançamentos são tão tranquilos, corrigir os poucos erros que passam também fica mais rápido e fácil.

Assim como um software mais acessível é mais fácil de usar para todos nós, um software mais testável pode ser mais fácil de compreender e manter. Pensar nos testes desde cedo pode levar a uma melhor separação de responsabilidades e a uma arquitetura geral mais resiliente.

Melhorar a experiência do cliente é nosso objetivo. O shift-left pode eliminar alguns incidentes que os usuários poderiam enfrentar e reduzir o impacto de outros. Podemos usar a observabilidade para completar esse ciclo de feedback e melhorar a integridade geral do nosso software.

Com ferramentas de automação poderosas à nossa disposição, pode ser tentador implementar todo tipo de teste em cada linha de código. Essa abordagem é um caminho perigoso.

Testar efeitos colaterais, como verificar se aquele registro foi salvo no banco de dados, é uma ideia atraente. Mas testar detalhes de implementação é um antipadrão, porque esse tipo de teste é frágil. Eles podem precisar ser alterados toda vez que sua aplicação for modificada. A interface do usuário também é um detalhe de implementação, então os testes de IU estão no mesmo barco.

Os testes de verificação se importam apenas com o "o quê", não com o "como" ou o "porquê". O ideal é que os requisitos do usuário tenham sido concebidos para validar o "porquê". Para responder ao "como", podemos contar com uma automação mais poderosa na forma de uma plataforma de observabilidade.

O teste shift-right é a prática de testar mais adiante no processo de desenvolvimento, geralmente em ambientes de produção. Embora possa parecer estranho, os testes shift-left e shift-right são complementares.

O teste shift-right nos permite identificar problemas de produção antes dos nossos clientes. Os ciclos de feedback mais curtos do teste shift-left nos dão a capacidade de responder a esses problemas de produção e corrigi-los rapidamente.

Os testes sintéticos de API como parte da sua plataforma de observabilidade são a forma perfeita de combinar os benefícios das práticas de shift-left e shift-right.