 |
|
 |
 |
|
|
 
Konstantin I. Boudnik's BlogJava. Quality. Metrics (part 6)Posted by cos on March 15, 2006 at 05:20 PM | Comments (0)Hi there. In this short article I'll try to summarize what I was discussing for the last couple of months. So, let's briefly list key factors that are likely to affect our judgment of software quality. - our code quality expectations (good enough quality, remember?) - coverage isn't everything - code complexity and a frequency of the changes - number of bugs filed against source code modules/files - testing methodologies Alas, the last one doesn't sound like a beast, it might reduce the effectiveness of defects discovery rate a lot. Obviously, it is a choice of approaches of test failures analysis. The bulky one with a weak algorithm of false positives detection pisses off engineers and they begin ignoring most possibly important warnings and notifications. Anyways, I want to talk about a combination of the first three bullets above. About a year ago, a few of Sun's fellas were chatting about simpler ways of delivering a better code. Static analysis and variety of testing approaches were among the things on the table. At some point, the bright idea of mixing both of those and adding some other flavors had appeared. Afterwards, we came up with what was called Buggy Spots Prediction (BSP). The idea itself is as follows:
As any heuristic approach, this one might produce incorrect results. However, our preliminary predictions are quite coherent to the fact that most of externally reported defects were found in the poorly covered but frequently called methods. In organization with limited QE resource, a manager might want to firstly address such hot spots. This will help achieve a good-enough quality level and then concentrate on less important issues. Yet another benefit is that the technique is a language independent. Once you'll build a universal presentation for CFG and code coverage information, you can use the same engine to measure Java, C++, and programs written in other languages. And, of course, our methodology doesn't replace a human knowledge of the importance of product features. It helps engineers see a valuable projection of static-to-runtime boundaries and helps focus on some aspects of that complex matter. And I just want to remind to you about Project Mustang (Java6) Regressions Challenge. Please check here for more details. CU, Cos Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment | |
 java.net RSS Feeds
|
