Descubra o que é Shift-Left Testing
Dicas de como utilizar essa abordagem no dia a dia
Um processo de desenvolvimento de software tradicional é sequencial, onde uma fase precisa terminar para começar outra. Normalmente, as fases seriam: Análise de Requisitos, Arquitetura de Software, Desenvolvimento, Testes e Implantação. Ou seja, todo o esforço de testes é previsto para acontecer somente no final do processo. Por esse motivo, os testes estão "à direita" no processo, como pode ser visto na imagem abaixo.
Quando o processo de desenvolvimento de software é visto como um processo sequencial, que vai da esquerda para a direita, antecipar as atividades de testes pode ser visto como “deslocar essas atividades para a esquerda”.
Shift-Left Testing significa mover o início da fase de teste para esquerda, ou seja, ao invés dos testes ocorrerem só nos estágios finais, as atividades de testes passam a ocorrer mais cedo, e perduram durante todo o ciclo de vida.
A imagem abaixo ilustra a atenção que é dada à qualidade no modelo Shift-Left e no modelo tradicional.
Você deve estar se perguntando: “ué, mas eu já faço isso!”
Será mesmo? Se seu time usa metodologia ágil não significa que, necessariamente, você já testa cedo. Ter uma coluna “In Test” no seu board ágil não significa que testes estão sendo feitos cedo. Se as atividades de teste são deixadas para depois que uma tarefa é desenvolvida, então você está testando tardiamente, muito próximo à entrega. Não há nada de Shift-Left nisso.
Já encontrou defeitos que poderiam ser evitados se a descrição da funcionalidade estivesse mais clara, e os critérios de aceite melhor detalhados? Se você tivesse atuado desde o início teria percebido essas lacunas.
Isso não significa que basta participar do refinamento do backlog para “ser Shift-Left”. Há inúmeras atividades que a pessoa QA pode antecipar. Se envolva com as decisões de arquitetura, escolha de ferramentas e frameworks, levantamento de riscos, negociações com o cliente, alinhamento de expectativas sobre o que é qualidade pro cliente e pro usuário, configuração de ferramentas de teste, trabalhar na definição de pronto (Definition of Done), dentre outras. Execute estas atividades utilizando seu senso crítico e conhecimentos sobre boas práticas em prol da qualidade.
Por que adotar essa prática?
Um dos motivos é que bugs serão identificados mais cedo, portanto, serão mais fáceis e mais baratos de corrigir, conforme a Regra 10 de Myers em seu livro “The Art of Software Testing”, em 1979. Passaram-se 42 anos, e o que mudou? Pudemos aprender com a Engenharia de Software e as metodologias ágeis, que ganharam força com o passar dos anos, e trouxeram práticas e princípios que beneficiam a abordagem Shift-Left e assim, temos a oportunidade de aplicar o que Myers pregou em seu livro.
Além disso, é mais fácil para um desenvolvedor trabalhar com um código que está fresco em sua mente, então o problema será resolvido mais rápido. Problemas descobertos por testes em um estágio avançado podem causar atrasos e até mesmo insucesso de projetos.
Buscar qualidade não é apenas encontrar inconsistências, mas principalmente planejar e executar estratégias para preveni-las e, caso existam, as encontrar o mais cedo possível. Por estas razões é que a abordagem Shift-Left deve estar na alma de todo o time!
Metodologias ágeis fortalecem a abordagem Shift-Left Testing
Um dos objetivos explícitos do manifesto ágil é o foco na entrega de software com qualidade e valor agregado. Para se beneficiar da metodologia ágil, os times devem seguir práticas e princípios durante todo o ciclo de vida do software. A cultura de qualidade é um desses princípios.
A abordagem Shift-Left pode e deve fazer parte da cultura de qualidade de um time ágil.
A pessoa QA se torna protagonista na disseminação e estruturação dessa cultura. Este protagonismo vem da sua responsabilidade em engajar o time na prática da estratégia de qualidade que foi definida. A pessoa QA deve atuar de modo que esteja claro que a responsabilidade pela qualidade é de todo o time, não apenas da pessoa QA.
Cada indivíduo passa a ser um representante da qualidade. Logo, todas as pessoas precisam adquirir a mentalidade de quem testa, a mentalidade de quem analisa riscos e busca qualidade para o produto.
O papel da pessoa QA é tão importante que o ideal seria que o mesmo participasse de todas as decisões que são tomadas. Infelizmente, nos times é comum haver apenas uma pessoa QA, como demonstra uma pesquisa de Júlio de Lima sobre a configuração dos times. Por isso, é inviável a presença da pessoa QA nesses momentos. É aí que a cultura de qualidade entra e torna possível envolver a mentalidade da pessoa QA, representada pelo desenvolvedor ou qualquer outro papel.
Ao adotar o Shift-Left, a pessoa QA deve se preocupar em transmitir para o time o que isso implica na PRÁTICA, o que muda e o que o time tem a ganhar com a adesão a essa mentalidade de antecipar atividades de testes.
Como a agilidade contribui para o Shift-Left Testing?
Ao adotar metodologias ágeis se torna ainda mais fácil disseminar esta cultura, principalmente pelas seguintes razões:
- Agilidade envolve feedback rápido e frequente: tenha CI/CD, code review, identifique riscos desde o início do desenvolvimento, utilização de linters e análise estática durante o desenvolvimento, reuniões diárias (dailies);
- Mais colaboração e menos isolamento: QAs e desenvolvedores devem trabalhar juntos, no mesmo time, e desde o início, ao invés de formarem grupos isolados. Outra opção é adotar pareamento;
- Envolvimento do cliente: o cliente está próximo dando feedbacks e validando os entregáveis. Tal proximidade ajuda o time a entender as reais necessidades dele, e a ser mais questionador e a identificar o valor da entrega de cada sprint;
- TDD: é um dos pilares do Extreme Programming (XP) de Kent Beck que propõe que o desenvolvimento seja feito juntamente aos testes;
- Padrões de codificação: também é sugerido pelo XP. Adote estratégias que incentivem o uso de um padrão de codificação único para todo o time. Os padrões de codificação mantêm o código consistente e de fácil entendimento e manutenção. Isso diminuirá o número de bugs à medida que estes padrões evitam códigos ruins ou inseguros.
Fazer Kick Off corrobora com a abordagem Shift-Left Testing
O Kick Off, na tradução literal, seria ‘ponta-pé inicial’. Ele acontece quando as pessoas desenvolvedoras estão prontas para começar um novo card (história de usuário, tarefa ou débito técnico). Trata-se de uma cerimônia rápida - entre 5 e 15 minutos - com o objetivo de entender o que deve ser feito, segundo o artigo “Defect Prevention Using Agile Techniques”. É uma excelente oportunidade para realizar verificações e validações acerca do que se pretende entregar. Abaixo, 10 perguntas para guiar um Kick Off eficaz:
O refinamento do card foi feito?
Está completo com detalhes e todas as informações relevantes?
O valor de negócio está claro?
Há dependência com outros cards?
Existe alguma dívida técnica relacionada a ele?
Há algum protótipo?
Há mensagens de erro previstas?
O escopo está num bom tamanho ou é melhor quebrar em mais cards?
O “caminho feliz” e os fluxos alternativos estão claros?
Como pretende testar?
Todas essas perguntas ajudam a fixar na mente do time sobre as expectativas quanto à qualidade com relação àquele escopo. Isso evitará retrabalho, informações dúbias, incorretas ou incompletas e, consequentemente, evitará que seja desenvolvida uma funcionalidade errônea e com defeitos.
Fazer Desk Checks também corrobora com a abordagem Shift-Left Testing
Segundo o artigo citado acima, o Desk Check é uma cerimônia rápida (entre 5 a 10 minutos) que ocorre logo após o desenvolvimento de um card. As pessoas desenvolvedoras que trabalharam no card se reúnem com as pessoas analistas de negócios, designers, e QAs com o objetivo de:
- Verificar o que foi desenvolvido
- Realizar testes rápidos e verificações para confirmar que os critérios de aceitação foram cumpridos
- Encontrar defeitos
Abaixo, 10 perguntas para guiar um Desk Check:
A nova feature faz o que é esperado?
Há algum comportamento não previsto?
Cobre cenários alternativos e o “caminho feliz”?
Qual a cobertura de testes para esta feature?
Passou pelo code review?
Foi verificado se a implementação pode ter impactado outra parte do sistema?
Todos os critérios de aceitação estão cobertos?
É necessário algum tipo de melhoria ou correção?
A implementação está de acordo com o design da interface?
Foram verificados se haviam erros gramaticais nos textos?
Estas perguntas ajudam a garantir que se desenvolveu a coisa certa do jeito certo. O Desk Check deve ser conduzido no ambiente de testes (não confunda com ambiente local) e, se forem encontrados defeitos, eles não precisam ser registrados formalmente. O card volta para o desenvolvimento para serem feitos ajustes, ou se o valor de negócio do card tiver sido atingido, pode-se abrir débitos técnicos e dar o card como concluído.
Testes baseados em Riscos corroboram com o Shift-Left Testing
Testes baseados em riscos é uma abordagem importante para prever e mitigar inconsistências na aplicação. Segundo Gabriel Santos, uma de suas vantagens é que as features mais críticas são desenvolvidas e testadas primeiro, de modo a reduzir o risco geral no projeto.
Automação de testes é essencial
A automação reduz os erros humanos, aumenta a confiança na entrega e permite que sobre mais tempo para as pessoas focarem em tarefas mais desafiadoras/inspiradoras do que passar dias fazendo testes exaustivos!
Ideia final
Pessoa QA, advogue pela qualidade de forma estratégica. Proponha pequenas práticas, pouco a pouco, e construa a mentalidade do seu time. Use as dicas simples desse artigo para melhorar sua estratégia de qualidade. Mudanças simples de mentalidade já surtirão efeito. Parte do papel da pessoa QA é transmitir, de forma simples, a estratégia de qualidade, muito mais do que inventar estratégias mirabolantes que ninguém consegue executar na prática. Prefira o simples e eficiente ao robusto e sem sentido.
Referências
- Shift-Left — www.devopedia.org/shift-left
- Defect Prevention Using Agile Techniques- www.thoughtworks.com/insights/blog/defect-prevention-using-agile-techniques
- O que é teste Shift-Left? — www.testim.io/blog/shift-left-testing-guide/
- Shift-Left Testing — www.browserstack.com/guide/what-is-shift-left-testing
Agradecimentos
Agradeço aos revisores desde post: Cristhiane Jacques, Gabriel Santos, Júlio de Lima, Rafael Albuquerque, Rafael Bandeira e Vanessa Redes.
