Thanks:  0
Likes:  0
Dislikes:  0

# Thread: Defects per thousand lines of code is acceptable?

1. ## Defects per thousand lines of code is acceptable?

I need to understand how to measure a software quality, testers job not just stops after completing the execution &amp; finding defects, but I believe one needs to understand how many defects identified per thousand lines of codes. Share the tricks to map identified defects with Line of code for both UAT &amp; System testing, is interacting with development team is the only solution??

2. ## Re: Defects per thousand lines of code is acceptable?

First thing you need is a threshold of acceptable defects per thousand lines of code. If it is software to control an airplane, the threshold is much different than if you are writing code to control this forum.

3. ## Re: Defects per thousand lines of code is acceptable?

If you have access to the source code, then you can count the number of lines.

If you have access to the bug reporting system, then you can count the number of defects.

I imagine you can do both without interacting with the development team, if that is your preference for some reason.

The rest, as they say, is just math.

4. ## Re: Defects per thousand lines of code is acceptable?

Yes, and IMHO, one more key thing to remember is that though defects/KLOC is a good start, what it produces is an "average". Average of 2 and 18 is (2+18)/2 = 10, and for 8 and 12 also it is (8+12)/2 = 10.

I am unaware of a practical metric but the general problems of using defects/KLOC are:

1. Time. It does not reflect the 'time' when the defects were created. This may be important for several reasons, for example if one were to perform some causal analysis to optimize their SDLC.

2. Type. General defects/KLOC gives similar weightage to all defects. Severity - there could be a low defects/KLOC but of bugs that cause a lot of damage if left unfixed, and also take time to fix (let us assume). And a high defects/KLOC of trivial bugs that can stay in, in the order of fixing.

I am not sure if this idea will be encouraged in your environment, but in the modern systems, you may want to build metrics of your own based on the context of your application factoring of functional_areas, layers in architecture (front/back/mid etc), injection points in time etc. You will have to really try and see which ones are giving some actionable information, rather than having a lot of metrics in a spreadsheet.

This is just an opinion based my experience but I am sure some people might have benifited using defects/KLOC at least in the past.

5. ## Re: Defects per thousand lines of code is acceptable?

i am agreed with "DSquared"

we can't judge the quality of product on defect per XXXX of lines of code. there are few things which i want to share about how to judge the quality of product.

1) application should match with Specifications
2) there should not any/ very few defects on General flow of application.
3) Application should pass Performance testing, Stress testing and Unit testing criteria

if above things are ok then Application is good [img]/images/graemlins/smile.gif[/img]

there are lots of Parameters which we need to consider while doing testing..

1) Actual Application(implementation or actual use) of Application which we are creating
2) Level of Accuracy
3) Cost
4) Skillsets and manpower
and many more....

3)

6. ## Re: Defects per thousand lines of code is acceptable?

I need to ask a couple of questions. Why would defects per lines of code would have anything to do with UAT? Secondly, this understanding the defects per lines of code is only one indicator of quality? Finally, I'd suggest that interacting with the development team is only one solution and not the only solution.

Other indicators of quality from my experience would be to employ 'Defect Mining' analysis, which is to identify which module and / or screen and / or tabs and / or fucntion and / or process have a higher number of defects and do a targetted test of this / these areas.

In the final build if you can employ a code freeeze prior to packaging, I have a tendency to my team to retest all closed defects detected between S1-S3 to re-prove that what has been fixed remains fixed.

Downward trending of defects over the test phase to prove stability. Specifics, could be closing more than you're raising, but you need to be mindful of the execution schedule and where test cycles start / stop.

Exit criteria met - moving from one phase in the SDLC to another or one test phase to another

Success Criteria met - meeting the business expectations that requirements have been tested and met. No outstanding S1 or S2 severity defects and S3 accepted with documented workaround and an agreed delivery schedule for the permanent solution, in agreeance with Business Sponsor, Test Manager and Project Manager as applicable.

Audit trails from Requirements to Test Cases / Scenarios / Scripts as applicable.

As with other things to do with Quality, some things are tangible and some things aren't and we need to take a holistic view to get confidence that we've delivered what is expected.

Just my 5 cents worth [img]/images/graemlins/smile.gif[/img]

Cheers
Chris

http://jetstream07.blogspot.com/

7. ## Re: Defects per thousand lines of code is acceptable?

defects per line of code has limited usefulness here is an example of why:

I am supposed to be writing a HR system for ACME Telecoms I write a ten thousand lines saying:

Print "I am a fish"

That means one defect ten thousand lines of useless code but a result of 1 in 10000 on this method.

I would find the number of defects against a system more use with a measure against them of severity and priority. That way you could say this system change caused 20 Severity 1, Priority 1 defects that would prevent use of the system so I am rejecting the build you could also classify what is acceptable. Saying 2 severity 4 Priority 4 defects is an exceptable exit criteria for the release.

Hope this helps

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.