Como antecipar a qualidade antes da execução formal de testes?

Durante o encontro “T01.01 — Por que Qualidade Importa de Verdade”, do QA Transform, um participante fez uma pergunta importante: como antecipar a qualidade antes mesmo da execução mais formal de testes?

A resposta curta é: aplicando Shift-Left.

Mas Shift-Left não significa apenas executar mais cedo os mesmos testes que já fazemos hoje. Significa trazer conversas, critérios, validações e decisões de qualidade para etapas anteriores do desenvolvimento, quando ainda é mais simples evitar um defeito do que corrigir suas consequências.

Em muitos times, o fluxo ainda acontece assim: a demanda é entendida, o código é desenvolvido e, só depois, a solução chega a uma etapa formal de testes. Na prática, isso pode transformar qualidade em uma inspeção no final da fila.

E quando a qualidade chega apenas no final, geralmente chega tarde.

Um requisito ambíguo, uma regra de negócio mal compreendida ou uma exceção esquecida não nasce quando o defeito é encontrado. Ele já estava presente em alguma decisão anterior. O teste apenas tornou visível o que o processo deixou passar.

Por isso, defendemos uma mudança de perspectiva: qualidade deve estar embutida em cada atividade do ciclo de desenvolvimento. Esse princípio é conhecido como Built-in Quality, ou qualidade embutida. Em vez de depender de uma pessoa ou de uma área para “garantir qualidade”, todo o time contribui para construí-la.

Onde entram os diferentes testes?

Uma forma de visualizar essa construção é a Pirâmide de Testes. Ela organiza os testes em níveis, considerando velocidade, custo, abrangência e proximidade do código.

Na base ficam os testes unitários: numerosos, rápidos e voltados para as menores partes verificáveis do código. Acima aparecem testes de integração ou de serviço, que observam se diferentes partes funcionam juntas. No topo ficam testes de interface ou ponta a ponta, próximos da experiência real do usuário.

Todos têm valor. A pirâmide mostra que não é eficiente depender principalmente de testes amplos e lentos para descobrir problemas que poderiam ter sido encontrados perto do código.

Foi no contexto da pergunta do participante que, durante o encontro, falamos de TDD — Test-Driven Development, ou desenvolvimento guiado por testes.

O TDD foi desenvolvido por Kent Beck no fim dos anos 1990 e ganhou espaço como uma das práticas de engenharia do Extreme Programming. Sua proposta é usar testes unitários para orientar a construção do código, aproximando a validação do momento em que a solução é desenvolvida.

Na prática, quem aplica TDD é o desenvolvimento. O ciclo costuma seguir três movimentos:

1. escrever um teste unitário que represente uma condição técnica e que, inicialmente, falhe;
2. escrever o mínimo código necessário para fazer esse teste passar;
3. refatorar o código, mantendo o teste aprovado.

Esse ciclo é conhecido como vermelho, verde e refatorar.

A ordem é essencial. Um time pode criar testes unitários depois de escrever o código e, ainda assim, não estar fazendo TDD. No TDD, o teste vem antes e ajuda a conduzir a implementação.

Também é importante não confundir TDD com BDD, ou Behaviour-Driven Development (guiado por comportamentos). O BDD costuma descrever comportamentos esperados em uma linguagem mais próxima do negócio. O TDD, no contexto apresentado, trabalha mais perto do código e de pequenas condições técnicas verificáveis.

Como isso aparece no mercado?

Imagine um e-commerce que precisa calcular descontos combinando valor da compra, tipo de cliente e período promocional. Com TDD, o desenvolvimento pode começar por condições pequenas: um cliente elegível deve receber determinado desconto; uma combinação inválida não pode ser aceita; o valor final deve respeitar um limite definido.

Em uma fintech, a mesma prática pode apoiar regras de juros, limites de transação ou validações de cobrança. Em uma plataforma de assinaturas, pode ajudar em cálculos de renovação, cancelamento e mudança de plano.

Esses testes não garantem sozinhos que toda a experiência funciona. Eles não verificam, por exemplo, se a interface está clara, se os sistemas externos estão integrados corretamente ou se existem riscos de segurança. Por isso, TDD e testes unitários não eliminam os outros níveis da Pirâmide de Testes. Eles fortalecem a base das demais validações.

Qualidade continua sendo responsabilidade compartilhada

TDD é uma prática aplicada pelo desenvolvimento, mas antecipar qualidade depende de mais pessoas.

Produto contribui ao transformar objetivos em critérios claros e reduzir ambiguidades. 

Negócio ajuda a explicitar riscos, prioridades e exceções. 

Desenvolvimento constrói com testes unitários, revisão de código e boas práticas técnicas. 

QA amplia a visão de risco, estrutura estratégias de teste e investiga cenários ainda não 

considerados. 

Liderança cria condições para que qualidade não seja a primeira coisa descartada quando o prazo aperta.

Isso não elimina uma área de QA nem a execução formal de testes. Também não substitui testes exploratórios, validações com usuários, análise de métricas, segurança ou revisão de produto. O que muda é o lugar ocupado pela qualidade: ela deixa de aparecer somente depois que o código está pronto.

Aplicar Shift-Left e tratar qualidade como responsabilidade compartilhada não é mover uma etapa para a esquerda no cronograma. É mudar o modo como o time trabalha: compreender melhor antes, validar próximo de onde cada decisão é tomada, automatizar o que faz sentido e combinar diferentes níveis de teste.

TDD contribui para essa mudança ao permitir que o desenvolvimento valide pequenas condições técnicas antes de escrever o código que deverá atendê-las. Não é a resposta completa para qualidade, mas é uma forma concreta de construí-la mais cedo.

Portanto, qualidade não começa quando alguém executa um teste. Ela começa quando o time entende que cada decisão, de um requisito ao código, pode aproximar ou afastar a entrega do resultado esperado.