Shift-Left Testing é um termo conhecido dentro da área de desenvolvimento de software quando falamos de qualidade.
Existem muitos artigos, vídeos e textos que explicam o conceito e passam um “how-to” de como aplicar em uma equipe e as vantagens estratégicas para a empresa.
A ideia deste artigo não é sobre como aplicar mas saber se está funcionando o Shift-Left Testing.
Este termo foi cunhado por Larry Smith em 2001 e no artigo dele tem alguns pontos interessantes e cruciais que raramente eu vejo alguém comentar:
No entanto, há uma pequena desvantagem nesse método. Ele equilibra sua carga de trabalho pessoal de forma tão eficaz que você se torna quase imune aos períodos de pressão intensa que costumam afetar quem ainda trabalha de maneira tradicional. Isso pode fazer com que você pareça “subutilizado”, como dizem os jargões gerenciais, pelo menos aos olhos da sua própria gerência de QA.
Nesse momento, é prudente marcar uma reunião de alinhamento com seu chefe direto e o gerente do projeto em que você está envolvido para desfazer essa ideia. Ao trabalhar com inteligência (e não apenas com esforço), você consegue entregar muito mais resultados. Mas cuidado: não deixe parecer que é fácil demais.
Neste artigo, gostaria de explorar estes pontos e entender quando o Shift-Left Testing está funcionando bem ou só estamos nos enganando.
“Subutilizado”#
Vamos entender por que quando aplicamos o Shift-Left Testing da melhor forma possível, as pessoas da equipe ficam “subutilizadas”.
Vamos trocar o termo “subutilizado” para tempo livre.
Ou seja, o primeiro sinal importante de que o Shift-Left Testing está funcionando bem é se todos da sua equipe estão com tempo livre dentro do horário de trabalho.
Se uma pessoa trabalha 8 horas/dia, quer dizer que esta pessoa consegue realizar todo trabalho necessário em 5h~6h.
Esse é o principal sinal de que Shift-Left Testing está funcionando bem. A qualidade é considerada prioridade na equipe.
Para explicar este fenômeno, vamos entender como funciona um processo com 5 etapas simples.
É muito comum, por exemplo, ver um kanban com as seguintes colunas:
Agora, vamos supor que não estamos conseguindo dar vazão na coluna QA e o time começa a acumular tarefas nesta coluna:
O que normalmente acontece nesta situação?
Eu já vivenciei as seguintes soluções:
- “Vamos chamar o QA do outro time para nos ajudar”
- “Vamos testar só o essencial e acreditar que o resto funciona”
- “Vamos fazer hora extra para terminar os testes”
Mas nenhuma delas funciona bem. Pois em nenhuma destas ações descritas acima estamos atacando o problema raiz.
Mas qual o problema raiz que o Shift-Left Testing nos ajuda a resolver? Por que se considerarmos testes e qualidade desde o início, sobra tempo livre para as pessoas e ainda não caímos em um contexto problemático como descrito acima?
Vamos continuar com o exemplo onde a coluna QA é gargalo. E vamos supor que cada etapa tem uma capacidade fixa de acordo com a composição do time 3 desenvolvedores, 1 techlead e 1 QA:
- DOING - Pode ter no máximo 3 cards pois tem 3 desenvolvedores
- CODE REVIEW - Sem limite mas só um techlead faz code review
- QA - Sem limite mas só QA trabalha nessa etapa
Ou seja:
- Do DOING para o CODE REVIEW podem passar no máximo 3 cards por vez
- Do CODE REVIEW para QA passa sempre somente 1 card por vez
- Do QA para DONE passa sempre somente 1 card por vez
Podemos redesenhar o processo então de acordo com a capacidade de cada etapa:
Agora, imagine uma corrente de água contínua no lugar de cards. O acúmulo de água vai acontecer da seguinte forma:
Ou seja, é natural que haja acúmulo dos cards. O processo foi desenhado assim e é um fenômeno natural da equipe.
Quando estamos nesta situação, o inesperado faz com que acumulamos mais tarefas pois não há como dar vazão. Qualquer tarefa inesperada cria um acúmulo no processo.
Algumas das consequências:
- Bugs começam a ter prioridades, já que o time não tem tempo para resolver todas elas
- Melhorias são ignoradas, pois afeta a entrega do time
- Piora no processo, no código e no produto.
- Começam a surgir um processo mais burocrático, pois confundimos a capacidade do processo real com a falta de organização
- São contratados mais desenvolvedores e QAs, pois confundimos a falta de eficiência com a falta de funcionários competentes
Como evitamos então a “enchente” no nosso processo? É muito simples. Nós controlamos a vazão da “água”, logo, devemos ajustar a vazão de acordo com o gargalo do nosso processo:
Assim evitamos a “enchente” no nosso processo.
No mundo dos cards, significa que cada etapa só pode ter no máximo 1 card em cada coluna:
E agora as pessoas da equipe começam a ter o tempo livre. Um time tem 5 pessoas mas só podem ter 3 cards sendo trabalhados.
Pode não parecer, mas esta é a situação inicial fundamental para começar a aplicar o Shift-Left Testing: Entender a própria capacidade do time e não sobrecarregá-la.
Este é o primeiro passo fundamental mas que 99% das equipes não conseguem dar, pois parece que as pessoas não querem trabalhar para a gerência e liderança!
Lembrem o que Larry Smith escreveu:
Ele equilibra sua carga de trabalho pessoal de forma tão eficaz que você se torna quase imune aos períodos de pressão intensa que costumam afetar quem ainda trabalha de maneira tradicional. Isso pode fazer com que você pareça “subutilizado”
Equilibrar a carga de trabalho é você e seu time entenderem o processo do time e a capacidade para depois adaptar-se de acordo com ela.
E se torna importantíssimo ter a estratégia alinhada com a gerência e a liderança neste ponto.
Temos tempo livre! E agora?#
Agora temos a situação onde 5 pessoas só podem paralelizar, no máximo, 3 cards. Uma em cada etapa do processo.
Temos tempo para realizar a melhoria contínua no tempo livre, aplicando o Shift-Left Testing!
Entendemos como um processo funciona e que não faz sentido sobrecarregá-la. Mas como qualidade contribui para a eficiência e qualidade do processo?
É muito simples. Vamos voltar para o nosso kanban onde só pode passar 1 card por vez.
E agora imagine que cada card tem uma probabilidade de ficar vermelho, roxo ou azul.
- Vermelho significa que a tarefa é defeituosa
- Roxo significa que é uma tarefa que não agrega valor para ninguém
- Azul significa que a tarefa foi feita com suposições
Vale a pena deixar estes cards passar pelo processo? A equipe só pode executar 3 cards, então vamos tentar filtrar esse tipo de cards o mais cedo possível no processo!
Pois estamos perdendo tempo importante no nosso processo com estes cards que vão gerar retrabalho.
É por este motivo que queremos o Shift-Left Testing: queremos itens de qualidade passando desde o início do processo para não perder tempo com itens que geram retrabalho.
Por exemplo:
- Vermelho - Itens com bugs, devemos detectar o mais rápido possível com testes rápidos
- Roxo - Não devemos adiantar itens do próximo sprint se ainda não temos feedback do cliente sobre a entrega atual
- Azul -Se uma tarefa, requisito ou nova funcionalidade gera dúvidas, vamos tirar estas dúvidas o mais rápido possível
Então a qualidade desde o início ajuda a termos um processo muito mais eficiente onde filtramos os itens logo no início para que eles não ocupem espaço das tarefas que geram valor!
E aqui um erro comum é começar com qualquer atividade de qualidade sem estratégia.
É muito normal tentar começar com testes automatizados, automação de etapas do processo e ignorar completamente o processo atual da equipe.
Devemos sempre começar onde o gargalo ocorre. O motivo é simples.
No nosso exemplo, o gargalo é o QA. Ajustamos a nossa capacidade de acordo com a etapa de QA. O que acontece se você deixar eficiente as etapas anteriores?
Você aumenta a capacidade de entrega mas não pode utilizá-la! Não adianta melhorar etapas anteriores e posteriores ao gargalo pois não tem como aproveitar a nova capacidade de entrega.
Então devemos pensar em como melhorar a eficiência do trabalho na etapa de QA primeiro:
- O teste é demorado pois a descrição da tarefa é vaga?
- O ambiente de teste é ruim para subir?
- Sempre que sobe o ambiente de teste, precisamos dar carga do cenário que depende de outras pessoas?
Faça melhorias contínuas em pequenos passos e com uma estratégia em mente.
Sempre considere o seu processo.
Eficaz#
Quando o time começa a criar soluções para trabalhar melhor naquela etapa, a eficiência do time começa a melhorar.
Por exemplo, vamos supor que a verificação da qualidade de um item que levava em média 4h, agora leva 30 minutos.
Isso significa que o mesmo item, com a melhoria no processo, ele passa muito mais rápido pela etapa de QA.
Quando isso acontece, a equipe vai perceber que o gargalo não é mais o QA e vai para alguma outra etapa.
Esse é o momento de realizar melhorias contínuas no próximo gargalo. E este é o ciclo fundamental para melhorar um processo de ciclo de desenvolvimento de software:
1 - Entender a capacidade da equipe e criar o tempo livre
2 - Entender onde fica o gargalo do processo
3 - Realizar melhorias contínuas no gargalo
4 - Repetir 2 e 3 para sempre
Quando este ciclo é respeitado e implementado corretamente, o time começa a entregar itens com uma qualidade muito melhor e com mais rapidez.
É nesta etapa que acontece o que o Larry Smith escreveu:
você se torna quase imune aos períodos de pressão intensa que costumam afetar quem ainda trabalha de maneira tradicional
Pode surgir um bug que o time tem tempo para resolver, todas as dúvidas do usuário final são respondidas, o time faz experiências de como trabalhar melhor a cada dia, alteração no sistema é fácil de realizar e fazer testes.
Um time eficaz é aquele que consegue entregar cada dia melhor, sem ficar sobrecarregado com as tarefas do dia a dia.
Sinais de que Shift-Left Testing não está funcionando#
A falta de tempo livre cria alguns sinais de que o Shift-Left Testing ou qualquer estratégia para melhorar a qualidade não está funcionando.
- Qualidade é uma tarefa que pode não ser feita (ex: documentação, refatoração, melhoria)
- O time tem backlog de bugs e prioridades para resolvê-las
- Permissão para resolver um bug ou refatorar um código
- Existe um time ou uma pessoa responsável para escrever os testes
- Existe um time ou uma pessoa responsável para realizar os testes manuais
- Devs frontend não conseguem ajudar os devs backend e vice-versa
- QA não conseguem ajudar P.M. e vice-versa
- Dev não consegue ajudar QA e vice-versa
Todos estes sintomas são consequências diretas da falta de tempo livre.
Quando o time tem um tempo livre, surge naturalmente um ambiente mais cooperativo e colaborativo.
Conclusão#
Shift-Left Testing é uma ideia que surgiu em 2001 e mesmo em 2025 é uma maneira de trabalhar que ainda muitas empresas e equipes não conseguiram adotar no dia a dia do trabalho.
É uma prática para considerar a qualidade em todas as fases do processo, antes, durante e depois.
Para aprender realmente a aplicar o Shift-Left Testing de forma eficiente dentro de uma equipe exige um conhecimento sobre a natureza de um processo.
Se tiverem mais curiosidade sobre o assunto ou quiserem sugerir um tema que eu conheça, podem falar comigo ou enviar um comentário!
🥒🥒 Espero que tenham curtido e até o próximo artigo! 🥒🥒