Recently, a colleague and I were discussing how to get the customer on board with tracking code coverage as a performance metric with respect to unit testing. While we both know that good code coverage usually means a better product and that Test Driven Development is being performed, how can you explain that effectively to a customer?
The following are the highlights of this conversation...
While code coverage is a great way to ensure your product works as intended, it does not guarantee that it meets the customer's functional requirements. Function testing is less automated, typically, but is more often used as acceptance testing for the customer.
|Code Coverage||Functional Coverage|
|Definition:||Code coverage tells you how much of the source code has been executed by automated testing.||Functional coverage measures how well the functionality of the design has been covered when performing testing.|
|Relationship to Design Document:||Sometimes references the design specification||Is directly correlated to the design specification|
|Who performs it:||Done by developers||Done by Testers|
For a developer, code coverage helps to determine what additional tests should be written. It also finds areas of the program that have an inconsistent level of maturity. Above all, when all unit tests pass and code coverage is high, the developer feels confident that the product is ready to move forward in the software pipeline.