Types of TC
How TC Tools Work
Software Testing and Test Coverage
It's all in the attitude.
If you are a developer testing software, especially software you have written, you want it to work -- you don't want to find bugs. Finding bugs means you've failed in some way. You didn't do the job right the first time.

But get real. You know there are bugs in that code. If you test some new code and don't find any bugs, then it's your testing that failed.

The attitude of a tester.
In a bigger shop, you can have dedicated test engineers. They want to find bugs. But they don't know the code like the developers, so they don't always know where to look. In a small shop, the developers are doing the testing. They need to learn to put on the test engineer's hat and get the attitude. The bugs are there, just waiting to be uncovered.
  First stop: the test suite.
Any test worth doing is worth keeping. Ad hoc testing with the mouse and keyboard is a small start. Every test should eventually be recorded and (hopefully) automated. Just because a feature works now doesn't mean some developer (probably working on something completely different) won't break it later. Regression testing is essential.

How Test Coverage can help.
Once you've started a test suite -- even if performed manually -- you're ready to measure its quality with a test coverage tool. It will probably be a shocking and sobering experience the first time. And then it will become both a motivator and a guide. You will see how much work you have to do. You will see where to focus your energy.

Test coverage is only a one measure of the quality of your testing. A perfect score will not ensure that your program is bug-free. And it can only guide you to the areas that need testing, not help you write the tests. But it is an essential minimum in developing a quality product.