Code coverage is one of those items that is better done by computer, yet people still insist on doing by hand.

When it comes to code coverage – estimating how much of your code is exercised by your testing regime – there are a number of top-notch tools. There are commercial tools for most technologies and open-source or bundled tools as well (just Google “open source code coverage”). You might think that, with all the effort and expense that is put toward software testing, development organizations would use these tools to accurately measure what their testing efforts actually buy them.

Not so.

Relatively few organizations do so, even when the tool is open-source and the only cost of ownership is the cost of installation, training and administration. The reasons are many: “Oh, our BA’s know the application so well, they can fully cover it,” or “The developers are handling that with their unit tests…,” or “We’re not there yet; we’re waiting until we shore up our core process.”

Well, maybe. Some reasons are better than others. Few organizations actually invest in even checking out whether there is an appropriate coverage tool for the technologies they are implementing with, or, if there is, what the cost might be. Some do invest in code coverage tools, and then only use them to measure the coverage of unit testing, but not the coverage of Integration or System testing. (Or UAT for that matter.) It is another area where the engineering and technology are mature and available, yet most organizations don’t take advantage of it. It is another example of how technology is ahead of process by leaps and bounds.