Conceito: Shift-Left é a prática de mover as atividades de teste para a esquerda no ciclo de vida de desenvolvimento (ou seja, para as fases iniciais). Em vez de testar apenas no final, testamos o mais cedo possível.
Por que "Mover para a Esquerda"?
O gráfico de custo de correção de bugs é implacável: um erro identificado na fase de Requisitos custa até 100x menos do que um erro identificado em Produção.
Bug no Requisito: Corrigido com uma simples conversa ou alteração no texto.
Bug em Produção: Envolve rollback, interrupção de usuários, novo ciclo de dev, novo deploy e possível dano à imagem da empresa.
Como aplicamos o Shift-Left na Neppo?
Para aplicar esse conceito, o papel do QA e do Desenvolvedor muda em cada etapa:
1. Refinamento e Planejamento (Planning)
O QA não é apenas ouvinte: Ele questiona regras de negócio, identifica lacunas nos Critérios de Aceite e sugere cenários de erro antes mesmo do código ser escrito.
Prevenção > Detecção: O objetivo aqui é evitar que o bug seja sequer codificado.
2. Desenvolvimento (Coding)
Testes Unitários: O desenvolvedor aplica a base da Pirâmide de Testes.
Pair Testing/Review: QA e Dev conversam durante o desenvolvimento para validar ideias de implementação sob a ótica de teste.
3. Definição de Pronto (DoD)
A qualidade é embutida na tarefa. Uma funcionalidade só "anda para a direita" (concluído) se ela foi validada em camadas iniciais.
Mudança de Mentalidade
Tradicional (Shift-Right) | Ágil (Shift-Left) |
QA testa o que o Dev entrega. | QA e Dev colaboram para construir o correto. |
O foco é encontrar bugs. | O foco é prevenir bugs. |
Testes são manuais e tardios. | Testes são automatizados e contínuos. |
"A culpa do bug é do QA que não viu". | "A qualidade é responsabilidade do time". |
Benefícios para o Time
Ciclos de Feedback Rápidos: O desenvolvedor sabe que algo está errado minutos após codificar, não dias depois.
Menos Retrabalho: Evita que funcionalidades inteiras sejam reconstruídas por erro de interpretação de requisito.
Maior Estabilidade: Builds mais limpas e deploys menos estressantes.
💡Próximos Passos para o Time
Participação Ativa: QAs devem estar presentes em todas as reuniões de refinamento técnico.
Escrita de Testes Antecipada: Criar os cenários de teste assim que a história é criada (BDD/Gherkin).
Automação na Base: Fortalecer os testes de unidade e integração para que a interface (UI) seja apenas a validação final.
Comentários
0 comentário
Escreva seu comentário aqui
Por favor, entre para comentar.