Pense no seguinte cenário:
Vc tem uma aplicação com X classes e vc implementou Y testes unitários.
Cada teste unitário diz respeito ao comportamento que vc espera de cada classe.
Vc executa essa suite, digamos com o JUnit, e executa junto o EMMA para ver a cobertura dos testes. Ai vc descobre que cerca de 23% do seu código foi coberto por estes testes.
E os outros 77% ? Vc não acha que é contra produtivo ter 77% do código sem qualquer tipo de cobertura? Vc não acha que é potencialmente perigoso? Que garantia vc tem q esse código FAZ o que se espera dele?
Agora pense que, por acaso vc gastou um tempão absurdo para deixar o seu codigo 90% coberto por testes. Ai vc precisa, uns 2 meses depois, adicionar novas classes. Vc adiciona e roda os testes – PIMBA, descobre que varios testes agora estão falhando pois vc alterou algumas coisinhas sem querer… não é melhor descobrir isso durante o processo de build, por exemplo, do que durante um custoso e demorado ciclo de testes ?
Tem quem não goste por diversos motivos: entre eles por preguiça ou pq não entendeu os testes unitários mas… o importante é vc pensar pela perspectiva de garantir o comportamento de uma classe que foi desenvolvida.
Sera q é tão ruim vc garantir o comportamento de algo que vc fez? Bom… tem gente q nem javadoc usa… 
Ok, antes o foco era: fiz uma classe e SEI/GARANTO q ela faz X.
Agora vc quer saber se tudo isso junto/reunido faz o que o programa deveria fazer. Ao meu ver uma coisa não exclui a outra mas… de novo vc deve pensar em termos de responsabilidade: compensa vc rodar os testes funcionar tantas e tantas vezes?
Vc fala roteiro, acredito que são testes manuais: vc vai ter q pagar X horas de um ou mais testadores para executar isso, enquanto uma suite de testes unitários uma vez q forem feitos basta um botão para executar. Não sei como seria compensativo vc usar um tipo de teste cuja execução é mais cara 