Java Champion / JavaOne Rockstar Adam Bien ( is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector. He is also the author of several books and articles on Java and Java EE technology, as well as distributed Java programming. adam has posted 59 posts at DZone. View Full User Profile

Quality Assurance Driven Development - And The Resulting Damage

  • submit to reddit
Everything started with the measurement of JavaDoc coverage. The equation was simple: the more coverage, the better the software quality. But the result is actually sad. When developers are forced to comment every piece of code, they will comment getters/setters as well. It's hardly possible to provide useful comments for straightforward code. The problem is not only in the writing: if you comment obvious code, someone will have to read your documentation too.

Recently, QA departments spotted the opportunity for measurement of unit-test coverage. This makes the situation even worse. Because writing unit tests takes time, it is often much easier to test obvious code in order to raise the test coverage. Meanwhile, I get suspicious when an average corporate project shines with test-coverage greater than 80%. The question then is: what do the remaining 20% consist of?

I encountered a more serious problem in an "agile" project (with a huge amount of unit tests): a considerable unit-test coverage of CRUD-cases (like masterdata management), while some really hard-to-test algorithms were simply skipped, causing problems in production. All because they simply wouldn't have contributed enough to the code-coverage results...

On top of that, you can even generate your tests to increase the coverage. Even System.out.println can be tested and the acronym would be cool as well: Code Driven Test Generation (CDTG).

In summary, instead of believing in numbers, sometimes a portion of common sense could really streamline your development. The problem here is that you then need to get rid of many buzzwords, acronyms, processes, and tools...


Quarterly_Quality_Assurance_Data.jpg5.65 KB
Published at DZone with permission of its author, adam bien.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Dan Dyer replied on Sat, 2008/05/31 - 11:43am

I agree, though I think a better title would be "Metric-Driven Development - And The Resulting Damage".  As you rightly say, it's not QA that's a problem, rather the fixation with metrics.

 I've previously written about the obsession with test coverage metrics. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.