This is the most common defense I hear when I talk about implementing testing on a legacy project. To this I want to walk through a scenario for finding and fixing a bug in a common organization. I know that not every shop runs like this and that every bug is unique but just humor me for a minute.

Role Task Time
(in hours)
User User notices something unexpected and tries to work around it themselves 0.5
User User finds the number for the helpdesk and reports the issue. The helpdesk attempts to troubleshoot the issue on the phone with the user to no avail 0.5
Helpdesk The helpdesk receives a call and attempts to troubleshoot the issue. It is determined it is a code bug and will need to be passed on. 0.5
Helpdesk Logs the issue and forwards it to the development department 0.5
Development Manager Development department determines that it is indeed a bug and determines the priority of the issue 0.5
Developer takes the assigned bug and determines how to replicate it 3
Developer corrects the issue and notifies manager 1.5
Development Manager Reviews fix (maybe) and marks it off work sheet, adjusts task lists and gant charts. 0.5
Developer/Build Master A new build is created with the fix(es) 0.5
Q.A. Tests the issue and logs it as a success or failure 1
Deployment Team Migrates the fix to testing environment(s) 0.5
User Tests to ensure the bug is fixed and has not affected other areas 2
Deployment Team Migrates fix to production 0.5
Helpdesk marks item as resolved and notifies the user 0.5
Helpdesk marks known deficiency in versions prior to current 0.25
7 users involved 15 steps 12.75 hours

If we say the average person here is making $85/hour this works out to just under $1084. And I was gracious with my estimates.

If a system gets 5 bugs a week: 5 X $1084 = 5420 / $85/hour = 63.77 hours = 8 days of effort

If more effort was putting into reducing bugs by adding testing then lots of money can be saved! Slowly the user becomes more productive, the helpdesk is less busy, the deployment team is doing less work, and the development team is less taxed under bugs. With all the savings across the organization you can hire more developers!

But how do you find time to do that when your team is overworked as it is under a slew of bugs and feature requests?

Simple. Don't do it all at once. You don't have to have 100% test coverage to improve quality. 1% over 0% is an improvement. If you have to tackle a bug, write a failing test to replicate the issue and then fix the issue. Ta-da regression test! You should never see that issue re-appear in your system (well unless no one runs the unit tests ever again). Maybe take 5-10 minutes while doing this to write a few other tests around the bug you just fixed too. Now the area you had an issue with has partial code coverage.

Just implement this stuff gradually and you will soon start to see the benefits.