Shift Left Testing é uma abordagem ágil que visa incorporar testes cada vez mais cedo no fluxo de desenvolvimento de software. Isso permite que defeitos sejam identificados e corrigidos antes se transformem em problemas maiores.
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?
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.
Conclusão
Aplicar shift-left testing trás inúmeros benefícios. A metodologia te 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. É caminho para garantir a qualidade do produto quando a empresa está em um ritmo mais acelerado, 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.
Escrito por: Thamyres Moraes
Referências:
https://www.testim.io/blog/shift-left-testing/
https://www.xenonstack.com/insights/shift-left-testing/
