Honestly, you may never be able to convince a budget pusher that testing will save money. What they see is a financial constraint that they may not be able to get around. As a coder, however, you can make YOURSELF more valuable by learning test methodology as a way of life. It has changed the way I think and code. My code is cleaner. I now deliver finished and stable product much faster.
First, let's look at the types of testing you may encounter. The most important, and easiest to introduce, is unit testing. Unit testing effects your approach to building clean, reusable modules. The second is regression testing, which is basically just the practice of keeping all your unit tests and running them ALL every time you add a new module or change an existing one. This keeps your bug fixes or functionality from "regressing". The next, if needed, is stress testing. This is important if you have an app that deals with a lot of data or a lot of user traffic. It helps you determine is there might be an issue with the chosen platform, database engine, even your network "pipes" clogging traffic. The last, and hardest to implement, is UI testing. That route usually requires a set of libraries that compile into your app. There aren't a lot of good ones out there, but the are some new stars rising in the field.
Let's get to the most important one now, unit testing. Unit testing, for a lot of languages can be implemented free and incrementally, which is how I started. If you are running C#, look into NUnit or even Microsoft's testing suite, built into pro versions of VS 2005 or greater. If C++, look at CppUnit. For Java, there is JUnit. If you are using SmallTalk (not very likely) there is the granddaddy of unit testing, SUnit, from which the rest derived. Even Flex and Flash from Adobe has FlexUnit. These are all free (or included in the development tools.) There are other projects out there for other languages but you'll have to research that yourself.
If you have never done unit testing get a book or three on Test Driven Development. It's a pretty large bite to chew, but give it time. This is more about improving your career than fixing a single problem. The basic idea is that, when you start solving a programming problem, break it down into small chunks and write a set of tests that will prove the code for each small chunk. Keep your classes small and focused. This will improve not only testability, but reusability, and inheritability (if those are even words). Don't tie UI code directly to the functionality behind it. This improves testability, but it also makes it easier to change out UI components when a wrong UI decision is corrected. For instance, if you program in a progress bar but the customer wanted a fuel gauge look, the functional code can service the different looks without changing.
Even with unit tested code you will still find bugs. The trick here is to make sure that 1) the classes are small and focused (mentioned earlier), 2) the class (and relevant unit tests) are well documented so that there is no guessing as to why you did what you did, and 3) the unit tests are well organized. When you run into a bug, sometimes just because of bad data in the real world, build a new test that duplicates the condition and fails (throws an error or somesuch), then modify the class(es) to handle the condition. Run that test again to make sure it worked. Then, lastly, run the full suite of tests that you built to see if you brake anything else with your change. This last test (regression testing) is the magic that makes unit testing shine.
I know that this post doesn't directly answer your question, but sometimes, a little understanding goes a long way to helping you ask the right question instead of guessing. Currently, I write about twice as much code as I used to. Half of it is unit tests (maybe more). The quality of my code, however, has greatly improved. I am also able to deliver cleaner code faster. Just like project management, where, if done right, you plan as much as you can up front and the project takes half the time, programming with testing as a part of the design will eventually) speed up your code delivery. It seems counter-intuitive until you have experienced it for yourself. Trust me, I put it off for twenty years before I "converted".