A idéia por trás de usar testes automatizados é possuir uma maneira rápida de se testar uma determinada aplicação. A etapa de testes em um processo tradicional de desenvolvimento de software é feitos após a conclusão da construção e, geralmente, feito de forma manual, o problema nesse caso é que é algo excessivamente repetitivo, caro, demorado e incerto. Quando você testa alguma rotinha do sistema e verifica que ela está ok, dificilmente você vai voltar nela para re-testar, pois você presume que não vai ter problema, afinal, você já o testou. Isso é normal e muito comum, é um trabalho muito chato ter que testar todo o sistema toda vez que fizer alguma alteração.
Produtividade elevada
Uma maneira de resolver esse problema é fazendo com que o computador teste para você, ele é muito mais rápido, barato, não torna seu trabalho repetitivo, pois não requer interferência do usuário e usando algumas métricas como Code Coverage você consegue ter uma lista de testes que te dê uma certeza do que foi e o que não foi testado.
Estes testes são escritos na forma de código fonte pelo próprio programador que escreveu a rotina a ser testado, uma técnica muito famosa nessa área é chamado de TDD que sugere que os testes sejam escritos antes do programa em si, existem vantagens significativas no uso desta prática, mas não vou entrar nesse assunto.
Outra prática muito interessante é a de Integração Contínua, onde você tem um ambiente que gera um deploy completo do seu código, executa sua suíte de testes e te deixa informado sobre os resultados. Se der certo, o produto está pronto para ser colocado em produção livre de bugs. Aqui vale uma observação, testes funcionando não significam que seu software não tem bug, mas te deixa ciente de que todos os bugs conhecidos e já testados nunca mais vão ocorrer novamente.
É comum pensar que ao utilizar testes automatizados não iremos mais precisar de uma área de testes, na minha opinião isso está errado e a área ganha ainda mais significado, ela precisa encontrar bugs, quanto mais bugs que ela encontrar, melhor. Todos esses bugs devem ser passados para a equipe de desenvolvimento que vai se responsabilizar de simular o erro usando testes automatizados, isso vai garantir que o mesmo bug nunca mais ocorra.
Quer saber mais sobre? Sugiro a leitura dos seguintes links, alguns conceituais e outros com exemplo de implementação. Se você trabalha com .Net e quiser aprender TDD, sugiro a leitura deste meu post.
TDD é uma técnica de desenvolvimento de software onde você escreve seus testes antes de escrever o código da aplicação. Parece estranho, não? Como você vai testar algo que ainda não está pronto?