I just ran across an (older) article about the difference between code coverage and code quality. The author argues that teams should not just rely on code coverage statistics. They should be more interested in the quality of the unit tests themselves.
As a QA engineer, unit testing has been one of the most difficult testing areas for me to deal with. As a non-developer and significantly poorer programmer than the developers I work with, I just don’t have the skills to review unit tests myself. And because unit tests traditionally fall into the developer’s task list–even though they are testing tasks–it’s been difficult to motivate the developers to think like QA engineers in order to implement unit test reviews or other means of testing the unit tests beyond basic code coverage stats.
It seems like this sort of process improvement should be easier to implement in an agile environment, due to the team focus and to the softer separations between roles. But so far, I haven’t had much success at fostering interest in delving into the types of issues raised in this article.
I’d love to hear how other non-programmers have helped to improve unit testing in their organizations.