It seems that my company is in the same phase as yours, but we've only got 2 programmers and are overwhelmed with projects. I've been trying to implement tests for the existing code base (most of it is nicely modularized) whenever I have spare time. It looks that the thing that will work is to start from the simplest thing you could test.

It took me weeks to try to come up with good testing infrastructure and then I realize that I should've just started it with whatever I've got and go from there.

For example, when you are testing scripts, you probably want to test whether each arguments will give you correct behaviour. The reason is because that's what you currently have and to be able to test each subroutine in the scripts requires you to modularize the script and put those subroutines into a module, and that's another hurdle. That could demotivate you from test.

TDD is good, but without enough testing experience you'd gain with simple tests like that, it is hard to be able to express your design in terms of tests. Frankly, I've never use TDD, but it seems that to do it properly, you need experience in testing existing code.

If you are still learning how to create module, you can also learn that from your tests. The idea is: start from testing the script then work your way to tests every single branch of your code, xgd called it top-down in the other comment. You can't test each subroutine in a script, unless you split that into modules. After you move them into modules, they'll be easier to test. Then you want to test the bits inside the module, you factor that bit out to another subroutine. So doing this gives you insight of how to create modular module.

So, the conclusion is: just do it. Training can only explain the modules you can use to test and how to use them, but to actually understand how to test, each member in your team must start doing it.