at least once every 2-3 months I see some bug I fixed come back, and I can only assume it's because we don't have a formal test suite.
Many have already mentioned that you need metrics if you want to prove that a test suite would be cost effective. You don't really say if that's to be automated and that's harder. You also don't say if the intent is module unit testing or integration testing or some other slice, nor do you say what technology the system is built around. 10 years probably would be VB6 and there was a unit testing framework a few years ago available but the tool-set is decidedly sparse AFAIK.
Anyway, the statement about bugs returning caught my eye. Perhaps they really are a regressive bug but take a close look at that idea. To illustrate suppose the complaint is that "a failure was not logged to the logging file". This could be *caused* by, among other things, a misconfiguration of the logging system, a missing logging statement within the code that handles the failure, a locked logging file which could not be written, use of a module that disabled logging, or which did not re-enable logging, and so on.
Since these are all discreet sources they really are different bugs. It's unlikely (disadvantageous actually) that one test would find re-emergence of all of these even though they result in the same basic problem.
The point I'm hoping to make is to be certain you really are identifying the same bug as haunting you not just similar bugs and be sure you can faithfully relate that to your stakeholders.
And if you can make that case then it should be a no-brainer that they'd *not* wish for their teams to spend time and their resources re-doing the same thing. At that point the question becomes "What's the best way to insure that we don't?"
Sometimes it comes down to better documentation of the modules being used or training of the people involved. It's very hard to quantify the cost of training folks to create useful tests that don't actually increase costs (a lot). Also hard is predicting the point of break-even where all the costs in training, tools, and coding (and testing) the tests have started to return enough that the net starts to be positive.
We often seek perfection but removal of all regressive bugs is probably not the best first step. Another clue I got was that these bugs are found late in the process. In any case, perhaps better defensive coding in the modules would make them more apparent or obvious, and found sooner or prevented from propagating in the development process or the system itself.
Can anyone offer suggestions for how to convince the owner that setting up a test suite is in his own best interest?
The question really is "Are they?".