Você já sentiu que o time de desenvolvimento passa muito tempo alternando correções de bugs e desenvolvimento? Esse é o sintoma clássico de um processo com qualidade tardia. Quando empurramos os testes para o final do ciclo, potencializamos loopings de correção que cobram um alto custo em tempo, custo e satisfação.
A abordagem Shift Left Testing propõe uma antecipação, trazendo a mentalidade de qualidade para a fase de ideias e requisitos. Este movimento não só previne problemas, mas garante e amplia uma melhor compreensão de cada desenvolvimento, pela soma de sua definição e plano/cenários de testes.
Incluir a qualidade desde o início do desenvolvimento de software – Shift Left Testing – reduz drasticamente os custos de correção e mitiga falhas. Quando analistas de qualidade (QA) contribuem desde a fase de levantamento de requisitos, mitiga-se falhas de comunicação, ambiguidades e cenários que seriam descobertos tardiamente.
Temos ganhos com esta prática, como economia exponencial (custo para corrigir um bug aumenta progressivamente no fluxo de desenvolvimento), maior previsibilidade (menos loops reduzem o tempo de desenvolvimento – Cycle Time), além de garantir um maior alinhamento e angajamento com a experiência do usuário.
Referências históricas com contribuições nesta discussão:
- Armand Feigenbaum (EUA ’20) – Qualidade é responsabilidade de todos!
- Philip Crosby (EUA ’20) – Defeito Zero! Fazer certo da primeira vez! Erro NÃO é inevitável!
- Genishi Tagushi (Japão ’20) – Qualidade é uma filosofia de trabalho para todos!
- Walter Schewart (EUA ’20) – Estatística (métricas) e Melhoria contínua.
- William Deming (Japão ’50) – PDCA. Qualidade não é uma etapa, papel ou fim de linha!
- Joseph Juran (Japão ’50) – Plano e controle. Pareto aplicado à organizações.
- Kaoru Ishikawa (Japão ’50) – Círculos de qualidade e Análise de causa e efeito.
- Cris Argyris (EUA ’70) – Aprendizagem individual x organizacional (Single/double loop).
- Eliahu Goldratt (EUA ’80) – Teoria das restrições. Qual o elo fraco, que origina o problema?
- Jeff Patton (EUA ‘2010) – Dual Track, Discovery e delivery, duas trilhas, mas um só time!
E2E – Não conformidades e bugs não se restringem a desenvolvimento, podem se originar da elicitação, modelagem e especificação, gerando ruído e mudanças evitáveis no desenvolvimento, riscos indesejáveis, retrabalho e desperdícios, aumentando a complexidade e entropia na comunicação intra e intertime.
FASE – Se qualidade é uma fase ao final (Inspeção Tardia), erros identificáveis de forma antecipada são descobertos após o desenvolvimento, gerando loops entre a fase de qualidade e desenvolvimento, trocas sucessivas de contexto (alternância entre tarefas), aumento de Cycle Time e baixa eficiência de fluxo (filas do loop).
ÁGIL – No Scrum, o Discovery/DoR deve antecipar o necessário para evitar retrabalho e desperdícios, incluindo o Plano de Testes. No Kanban temos o Upstream para o entendimento, priorização e especificação de uma demanda, oferecendo no Ponto de Comprometimento e início do Downstream esta antecipação.
GC – Um aspecto oculto pertencente ao fluxo contínuo de qualidade é a gestão do conhecimento para melhoria contínua, com técnicas como Pair Negotiation, Code Review, Chapters em participação proporcional desde o início (refinamento, planning, daily, review e retrospectivas no Scrum ou Upstream e Downstream no caso do Kanban).
DUAL TRACK – Jeff Patton sugeriu o modelo Dual Track, que materializa exatamente este viés, o Discovery (DoR ou Upstream) antecipa e interage permanentemente com o Delivery (DoD ou Downstream), de forma a gerar sinergia e aprendizados, mitigando ou eliminando desperdícios e loops desnecessários e evitáveis.
