Automated testing is often thought to be a bargain or a free lunch but even limited experience will have shown you that it's not something for nothing and not even always cheap, especially in terms of maintenance. You should think carefully about whether regression tests are appropriate, what you hope to achieve, how, using what resources and attempt some level of cost/benefit analysis (using whatever data, estimates, gut feeling you have available) before you start on an automation project to try to maximise its value.
But existing infrastructure can have unexploited value. For example, it is sometimes possible to double up regression test suites and test something other than what was originally intended.
In my company we have both a traditional software development team and a resource development team that produces plug-ins, such as configuration files for processing different source data formats. A software regression test will usually use a static set of data inputs with a variable executable, like so:
diff these against the golds (the expected results) to generate the report. A change needs investigation to see whether it's intended or accidental.
However, we can use exactly the same machinery to provide a regression test for the resource development team to use by making the configuration files variable too - perhaps we'll check the latest revision out of version control before running:
The same harness can be used with a static executable. When the resource development team are creating materials for a previous release, being able to run against an unchanging branch build is valuable. But remember that you need to be sure your golds are relevant to that build. (You do branch your test code base in sync with the product, don't you?)
Another way to exploit existing infrastructure is when you have two product components in a producer-consumer relationship. The first creates a resource and the second uses it. If you have a regression suite for validation of the consumer, you can reuse it in the test suite for the producer.
If this shows changes we may have accidentally broken the producer. This has more value still because the resource, once changes are validated, become the next set of static resource for the consumption suite, which saves us having to regenerate it manually:
You might never get your lunch paid for, but you could cover the cost of the starters if you always look for value: plan your test suites, cost them, build them efficiently and for extensibility when you can, run them as often as makes sense and look out for special offers like buy one, get one free.
Image: Salvatore Vuono / FreeDigitalPhotos.net