Shift Left Testing é uma abordagem ágil que visa incorporar testes cada vez mais cedo no fluxo de desenvolvimento de software. Desta maneira permite que defeitos sejam identificados e corrigidos antes se transformem em problemas maiores.
É da natureza humana, mas muitas pessoas tendem a adiar questões particularmente difíceis. A analogia de “Chutar a lata pela rua” vem à mente. Em última análise, isso leva a problemas significativos quando finalmente tentamos resolver o problema. O gráfico abaixo ilustra o que acontece. É também um indicador de que abordagens mais ágeis são necessárias.
Ao aplicar este método, o entendimento de todo o time sobre os requisitos, design de software, arquitetura, codificação e aspectos funcionais do sistema são amplificados.
O processo também faz com que os stakeholders estejam mais envolvidos nos projetos, e que dúvidas a respeito da funcionalidade ou projeto tanto em questões técnicas quanto de negócio sejam esclarecidas o mais cedo possível, fazendo assim, com que os ciclos de feedback e possíveis ajustes no planejamento das funcionalidades tenham um ritmo mais acelerado e enfatizando a qualidade desde o início.
Muitas vezes, mesmo com equipes ágeis, o teste é a última etapa do processo, fazendo com que o tester tenha o papel de apenas detectar bugs. E além disso, estas circunstâncias podem fazer com que a fase de testes se torne um gargalo.
Porque mudar para a esquerda?
A resposta é bem simples e direta, encurtar ciclos de teste mais prolongados
Um cenário típico: O tester encontra um bug e reporta para o time. O desenvolvedor gasta tempo debugando o sistema e percebe que na verdade o problema pertence a outro time. Mesmo que o problema tenha sido descoberto, os membros do time dedicaram muito tempo entendendo como o código funciona e tentando desenvolver uma solução. Enquanto essa correção não é aplicada, o tester fica impedido de continuar com os testes e as vezes as correções exigem que grande parte do sistema seja retestado, levando muito mais tempo do que o esperado para essa fase. Provavelmente se nesta situação o time tivesse conversado antecipadamente sobre os cenários, mapeado a funcionalidade e envolvido o outro time, teriam um conhecimento mais amplo do problema antes mesmo de escrever o código. Além disso, o planejamento e implementação de testes automatizados também poderia ajudar quando um reteste fosse necessário.
Quando o shift left é aplicado, o desenvolvimento de software é mais rápido e seguro. Então, quando chegar na fase de testes, o risco ter bugs é menor e fica mais fácil de executar os seus testes, pois, o time já tem propriedade sobre a arquitetura e a funcionalidade, e todos sabem exatamente qual deve ser o comportamento do sistema naquele ponto. Outro fator importante, é que com o shift left, a expansão da cultura de qualidade fica mais fácil, dado que com os cenários bem definidos e com a ideia de como o sistema deve se comportar clara para todos, não necessariamente, o QA precisa executar os testes, podendo passar essa atribuição a outros membros do time.
Custos reduzidos
Bugs são mais baratos quando são encontrados no início do desenvolvimento. Portanto, é primordial que o QA esteja atuando em todas as fases do desenvolvimento da funcionalidade ou produto em questão. Começando pela fase de concepção(Análise de viabilidade, levantamento e validação dos requisitos de negócio, validação da escrita das estórias e critérios de aceite, escrita dos cenários de teste/bdd’s), passando pela fase de desenvolvimento(Auxílio na escrita de testes unitários, participação ativa nos code reviews, análise da implementação realizada com o intuito de identificar gaps e possíveis novos cenários, desenvolvimento de testes automatizados que forem viáveis), chegando na fase de testes(Execução dos cenários propostos, seja de forma manual ou automatizada, manutenção e gerenciamento do ambiente o qual a funcionalidade será testada) até a entrega(Condução de reviews com os stakeholders, definição e execução da estratégia de implantação, e execução de um babysitting se preciso).
Melhor cobertura de teste
Começar atacando pela a esquerda também pode melhorar a cobertura do teste, pois o foco em verificar cada função do sistema com base no seu contexto de negócio em cada camada da aplicação durante todo o ciclo de desenvolvimento, é algo que acontece naturalmente quando se está aplicando o shift left. Esse foco com certeza leva a uma cobertura aprimorada de teste, que consequentemente, resulta em um produto melhor.
A equipe fala a mesma língua
Todos os membros da equipe precisam entender as necessidades do cliente. E para que isso aconteça, todos precisam falar a mesma língua. Uma boa estratégia para que isso aconteça, é adotar o BDD(desenvolvimento orientado a comportamento), que integra as regras de negócio com a linguagem de programação, e foca em expor de forma clara para todos o comportamento do software.
Equipe mais envolvida
A troca de informações desde o início do ciclo de vida do projeto, envolvendo o time em análises detalhadas sobre a funcionalidade e o produto, faz com que a equipe tenha feedbacks mais rápidos dando mais propriedade a todos sobre o que está sendo desenvolvido. Além disso, os desenvolvedores, com esse envolvimento aprimorado, podem colaborar de forma mais eficiente com os testes unitários, integrados e em outras camadas do sistema, o que resulta na redução de bugs críticos na fase de produção.
Implantação “Shift Left”
Acredite ou não, existem algumas maneiras de “Mudar para a Esquerda” de implantação e operações. No final, estabelecer um pipeline de entrega contínua é a resposta. No mundo dos aplicativos “Born in the cloud” executados em um ambiente de “Platform as a Service”, como o IBM Bluemix, a capacidade de implementar continuamente é muito fácil. Fazer isso para outros aplicativos pode parecer mais difícil. No entanto, para esses tipos de aplicativos “legados”, existem poucas técnicas que podemos usar para deslocar a implantação para a esquerda. Algumas dessas técnicas incluem:
1. Operações de modelos e padrões “aprovados”
Muitas organizações têm listas de verificação que precisam ser usadas para serem validadas antes que qualquer aplicativo possa ser implantado em produção. Infelizmente, eu vi uma série de etapas manuais que as operações devem seguir para aprovar uma implantação de produção. Em uma mentalidade “Shift Left”, devemos tentar codificar essas listas de verificação em modelos aprovados que o desenvolvimento pode usar anteriormente como uma base de desenvolvimento.
2. Testes automatizados que validam a lista de verificação de operações
Usando Test Driven Development, construir casos de teste que valida padrões de operação aprovados ajuda a construir confiança (e deve acelerar as aprovações na implantação de aplicativos). Construa esses casos de teste!
3. Automação
A automação é o recurso-chave de que precisamos e é a espinha dorsal de qualquer prática “Shift Left”. Automatizar uma implantação consistente de um aplicativo em todos os estágios (DEV, TEST, PROD, nuvem pública, nuvem privada, etc.) ajudará a aumentar a confiança na implantação. Compartilhar os resultados com as operações ajudará a criar confiança na construção de uma cultura que apóia a entrega contínua e nos ajuda a fazer essa mudança de paradigma no Shift Left
Conclusão
Implementar a metodologia shift-left testing trás inúmeros benefícios, pois dá a oportunidade de analisar o software sob uma perspectiva interna e externa e de forma em que toda a equipe entenda de forma clara como o software deve se comportar.
O que garante a qualidade do produto quando a empresa está ou necessita de um ritmo acelerado de desenvolvimento, pois tem o foco principal em prevenir problemas ao invés de apenas encontrá-los. Além disso, a aplicação do processo faz com que as chances de se acertar o código da primeira vez aumentem, reduzindo assim, o tempo de lançamento.
Abaixo disponibilizamos algumas matéria sobre o assunto.