Testes durante o desenvolvimento

"quanto mais cedo testar, melhor"
Eu não sei quem disseminou essa idéia, mas não acredito nela.
Imagine um sistema integrado. Você tem 10 telinhas pra construir.

• Faz a 1a, testa, corrige, re-testa, ok;
• Faz a 2a, testa, corrige, re-testa, ok;
• e assim por diante.

No final, quantas telas você tem ok? Nehuma!
Ah... aí você vai retestar tudo e começa a encontrar defeitos básicos que não deveriam estar lá. Aí vem os motivos:

• Ao fazer a tela 2, você destruiu a tela 1...
• Ao corrigir a tela 3, você destruiu a tela 1 e a 2;

O mesmo vale se você faz testes de componente. Ah... o ideal é retestar sempre, e para isso, obviamente, automatizar o teste.
Você consegue automatizar 100% das telas e rotinas? Não, nem se recomenda.
Você consegue vender um projeto de software cobrando o preço de uma automatização? (pessoas, ferramentas, documentação, manutenção de dados, scripts e documentação...)? NÃO, não consegue.

Então, pra resolver a equação eu proponho o seguinte: teste o mais tarde possível. Já que você vai ficar retestando sempre e sempre. Deixa tudo pro final. Cada programador testa sua tela ou rotina, libera quando achar que está legal e a equipe de teste só é usada no final da história.