Code coverage is a term that is used to describe how much application code is exercised when an application is running. Test coverage is often used to describe test cases that are written against the requirements document. Both are analytics which may be useful for quality assurance personnel to get an indication of how thoroughly an application has been tested. Let me explain a little bit more about how each of these can be used.

Measuring code coverage is a technique for understanding exactly which application code is being exercised. There are tools that can be used to indicate which code is being executed when running through test cases, for example. When I was a developer at IBM, part of what was required at IBM was to write unit test cases that would exercise every code path. If there was a code path that would only be executed in the case of an error condition, for example, I had to write a test case that would create that error condition and then verify that the appropriate error message was displayed. This type of testing is also referred to as "white-box" testing. You need to see the application code in order to assess the coverage.

Test coverage often refers to a set of test cases that is written against the requirements specifications. This would be "black-box" testing. It is not necessary to see the code in order to write the test cases. Once a document is written that describes all the test cases then test groups may refer to a percentage of the test cases that were run, that passed, failed, etc. These types of metrics can be referred to as test coverage metrics. Testing the code paths, or code coverage testing, is often done more as a part of unit test by the developer. Overall test coverage is often used by QA groups to indicate test metrics and coverage according to the test plan.