Introduction to KLOC
Lines of Code (LOC) is one of the software metric that is used by most of the people for Software Measurement. Thousand lines of code is treated as KLOC. This metric helps us in knowing the size and complexity of the Software Application. Click here for more details on KLOC. This info is from wikipedia
What does it mean to Software Testing
We do test applications with the intention to see if the promised functionality works fine or not. Any deviation here will be considered as a Bug. So each of these bugs must be originated from some line of code in the product.
So it’s understood that when the size of the code is more there is a chance for more number of bugs in the prodcut. Even most of the process to talk about some % of issues is fine or acceptable quality per KLOC(even though there is lot of subjectivity).
The Defect Density is arrived at Number of Bugs / KLOC per the product under test. The defect density is one of the metric used to measure the quality of the product. Most of the Quality Process does talk about this metric.
Concerns
The concern in this approach is that how these values are measured. The general bias with KLOC is that people try to see that only the excutable lines of code in the product.
Each every line in the product may not be code at all & we may not execute each and every one of them. So it’s not taken care, then the issues related to documentation, images, installation etc might be misleading.
Since we are looking at KLOC as the size of the product it’s better to include each and every entity that effects the same. Then it’s helpful for both development and test teams.
Authors bio is coming up shortly.
Agreed, the entities that effects this can be criticality of bugs, Lines of unreachable code. For example a product with bug density of 15 minor/KLOC is better than product with 10 major bugs/Kloc
Mallik,
Thanks for your comments.
The unreachable code (dead code) is the bottleneck incase if it exists for the Bug Density
The problem with KLOC is that you can not compare values between organizations (no one has the same defintions). I would suggest other sizing metrics such as Function Points as a size metric.
Tom,
Thanks for the suggestion on size metric
One big problem with “lines of code” as a metric: how much of your product is code that your organization wrote, vs. code that the operating system vendor wrote, that the BIOS vendor wrote, that the hardware vendors wrote, that the application framework(s) writer(s) wrote, that a third-party library writer wrote,…?
Function points abstract this problem into another dimension without getting rid of the problem at all.
—Michael B.
@ Michel,
You are right & thanks for the feedback. But KLOC is widely used as a size metric and it just considers the code that has been written for the application.
Venkat