Last time I discussed how I’m working on coming up with a framework for how to focus your testing efforts for maximum ROI.

Let’s back up though, and consider another simple, but incisive, question from my friend Luca Ingianni:

What is the goal of testing?

My quick answer: to catch bugs.

My more thoughtful answer, with two parts:

• to increase software quality up to the required standard
• to increase confidence that the software quality meets the required standard

We can’t prove the absence of bugs. We can’t prove the quality of our software.

It’s possible (not likely) that I could write perfect, bug-free software without testing it at all. This hypothetical software would have perfect quality.

Without testing, I don’t know what the level of quality is.

So, the more testing you do, the greater your confidence grows that the software is high quality.

If your testing doesn’t find any bugs, the actual quality of your software isn’t increasing. However, your confidence in the level of quality is increasing.

Finding and fixing bugs during testing actually increases software quality, as well as our confidence in it.

I wouldn’t sleep at night knowing that untested code of mine was out in the wild in a safety-critical setting, with lives depending on it. I’d have no confidence in the quality of the software.

I would test the hell out of it, and if the testing revealed no flaws, I wouldn’t consider the time spent testing wasted in the slightest. Why? I’d have confidence.

Actually, wait a second. If my testing revealed no flaws, I’d start to wonder if my testing was thorough enough. I’ve certainly never written perfectly working code the first time.

However, I can say that I have occasionally sailed through system testing with very few errors found, after I had unit-tested my code thoroughly.

For my money, comprehensive unit testing, enforced by test-driven development, is hands-down the best investment in software quality that I’ve encountered.

More on this next time.

Be safe out there.