Defect ratios [modified]
-
I'm curious as to everyones view as to what is an acceptable, or expected, ratio of defects per lines of code. I know, it should be zero, but let's stick to reality. ;P I currently have a project with about 9000 LOC and 52 reported defects during initial testing. 173:1 or 0.006% I consider this good, but a manager is frustrated with the "high" number, the client has refused to start testing and most importantly, is withholding payment. [edit] I should have clarified that 52 is after the first round of testing, not release. They are also classified, high, medium, low, with about 30% being low due to things like incorrect or necessary changes to requirements and only two high priority. [edit] As Electron Shepherd pointed out my calculations were flawed (I need a vacation). As a total it makes 57% which is very bad, but factoring out the low priority missing requirement defects lowers it a good deal and considering only two high priority defects it really isn't bad at all.
I know the language. I've read a book. - _Madmatt
modified on Friday, December 18, 2009 2:49 PM
-
I'm curious as to everyones view as to what is an acceptable, or expected, ratio of defects per lines of code. I know, it should be zero, but let's stick to reality. ;P I currently have a project with about 9000 LOC and 52 reported defects during initial testing. 173:1 or 0.006% I consider this good, but a manager is frustrated with the "high" number, the client has refused to start testing and most importantly, is withholding payment. [edit] I should have clarified that 52 is after the first round of testing, not release. They are also classified, high, medium, low, with about 30% being low due to things like incorrect or necessary changes to requirements and only two high priority. [edit] As Electron Shepherd pointed out my calculations were flawed (I need a vacation). As a total it makes 57% which is very bad, but factoring out the low priority missing requirement defects lowers it a good deal and considering only two high priority defects it really isn't bad at all.
I know the language. I've read a book. - _Madmatt
modified on Friday, December 18, 2009 2:49 PM
That's a pretty convenient metric you're using there, isn't it? Let's say your 9000 lines of code implement 100 different "features" and 52 of them are defective. The ratio looks a little different then, doesn't it?
-
That's a pretty convenient metric you're using there, isn't it? Let's say your 9000 lines of code implement 100 different "features" and 52 of them are defective. The ratio looks a little different then, doesn't it?
Dinobot_Slag wrote:
The ratio looks a little different then, doesn't it?
Of course it does. What's your point? Using this same argument then if one line caused a feature to be defective then one defective feature would make the entire application defective. A very poor ratio indeed.
I know the language. I've read a book. - _Madmatt
-
I'm curious as to everyones view as to what is an acceptable, or expected, ratio of defects per lines of code. I know, it should be zero, but let's stick to reality. ;P I currently have a project with about 9000 LOC and 52 reported defects during initial testing. 173:1 or 0.006% I consider this good, but a manager is frustrated with the "high" number, the client has refused to start testing and most importantly, is withholding payment. [edit] I should have clarified that 52 is after the first round of testing, not release. They are also classified, high, medium, low, with about 30% being low due to things like incorrect or necessary changes to requirements and only two high priority. [edit] As Electron Shepherd pointed out my calculations were flawed (I need a vacation). As a total it makes 57% which is very bad, but factoring out the low priority missing requirement defects lowers it a good deal and considering only two high priority defects it really isn't bad at all.
I know the language. I've read a book. - _Madmatt
modified on Friday, December 18, 2009 2:49 PM
Depends on the size. We have an application that is close to 4MIL LOC, and reportedly close to 20k defects, roughly 0.005% defects. A lot of it is generated code, so I guess you could factor that out, and the DAL to bring it down to about 1MIL bringing it closer to your 0.02%, which is acceptable enough for names like Puma, so it should be acceptable enough for your client. But in your case, I'd say the magic number is the number that makes the comfortable enough to pay you :)
Check out the CodeProject forum Guidelines[^] The original soapbox 1.0 is back![^]
-
I'm curious as to everyones view as to what is an acceptable, or expected, ratio of defects per lines of code. I know, it should be zero, but let's stick to reality. ;P I currently have a project with about 9000 LOC and 52 reported defects during initial testing. 173:1 or 0.006% I consider this good, but a manager is frustrated with the "high" number, the client has refused to start testing and most importantly, is withholding payment. [edit] I should have clarified that 52 is after the first round of testing, not release. They are also classified, high, medium, low, with about 30% being low due to things like incorrect or necessary changes to requirements and only two high priority. [edit] As Electron Shepherd pointed out my calculations were flawed (I need a vacation). As a total it makes 57% which is very bad, but factoring out the low priority missing requirement defects lowers it a good deal and considering only two high priority defects it really isn't bad at all.
I know the language. I've read a book. - _Madmatt
modified on Friday, December 18, 2009 2:49 PM
Personally, it seems to me that unless this is something negotiated and stated in the work contract then you may want to take this to legal and let them hash it out. The stuff I usually do has right in the work agreement that 'ready for release' can include 'X' number of P2, 'Y' number of P1, and 'Z' (typically 0) number of P0 (critical) defects. The hairy parts come then in the rules that are used to classify the defect into a category, but as long as the requirements are good that can help solve that.
-
I'm curious as to everyones view as to what is an acceptable, or expected, ratio of defects per lines of code. I know, it should be zero, but let's stick to reality. ;P I currently have a project with about 9000 LOC and 52 reported defects during initial testing. 173:1 or 0.006% I consider this good, but a manager is frustrated with the "high" number, the client has refused to start testing and most importantly, is withholding payment. [edit] I should have clarified that 52 is after the first round of testing, not release. They are also classified, high, medium, low, with about 30% being low due to things like incorrect or necessary changes to requirements and only two high priority. [edit] As Electron Shepherd pointed out my calculations were flawed (I need a vacation). As a total it makes 57% which is very bad, but factoring out the low priority missing requirement defects lowers it a good deal and considering only two high priority defects it really isn't bad at all.
I know the language. I've read a book. - _Madmatt
modified on Friday, December 18, 2009 2:49 PM
Maybe I'm misunderstanding, but a client's payment will be predicated upon some defect measurement? That sounds like a recipe for disaster. There should be an agreed upon payment/deliverable schedule. Even when the client has to go through acceptance testing, there should be a schedule for this as well. But I would stay away from metrics like LOC and number of defects. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
-
I'm curious as to everyones view as to what is an acceptable, or expected, ratio of defects per lines of code. I know, it should be zero, but let's stick to reality. ;P I currently have a project with about 9000 LOC and 52 reported defects during initial testing. 173:1 or 0.006% I consider this good, but a manager is frustrated with the "high" number, the client has refused to start testing and most importantly, is withholding payment. [edit] I should have clarified that 52 is after the first round of testing, not release. They are also classified, high, medium, low, with about 30% being low due to things like incorrect or necessary changes to requirements and only two high priority. [edit] As Electron Shepherd pointed out my calculations were flawed (I need a vacation). As a total it makes 57% which is very bad, but factoring out the low priority missing requirement defects lowers it a good deal and considering only two high priority defects it really isn't bad at all.
I know the language. I've read a book. - _Madmatt
modified on Friday, December 18, 2009 2:49 PM
Hmm... Our metric is simply the number of bugs reported. It's not pro-rated with the number of lines of code. That said, our active bug list usually averages less than 100 bugs per product, and our products average 500,000 LOC. 52 defects in 9,000 lines of code does seem rather high. Do you classify your bugs? We typically have 'critical' (the world is coming to an end, i.e. the customer ain't paying), 'major' (someone's panties are in a bunch), 'minor' (Q.A. is pissed), and 'cosmetic' (somebody prefers pink). If you had say, 1 critical, 3 major, 20 minor, and 28 cosmetic, that's not bad. If it's more like 18 critical, 20 major, 4 minor, and 10 cosmetic, then you've got troubles.
Mark Nischalke wrote:
the client has refused to start acceptance testing
That obviously begs the question: if they aren't testing, then what are they basing their refusal on? An acceptance test either passes or fails. In either case, there are certain contractual obligations for both you and the client. If it passes, the client is supposed to complete payment on the contract. If it fails, you go back and fix things until it passes, or you and the client modify the terms of the acceptance test.
Software Zen:
delete this; -
I'm curious as to everyones view as to what is an acceptable, or expected, ratio of defects per lines of code. I know, it should be zero, but let's stick to reality. ;P I currently have a project with about 9000 LOC and 52 reported defects during initial testing. 173:1 or 0.006% I consider this good, but a manager is frustrated with the "high" number, the client has refused to start testing and most importantly, is withholding payment. [edit] I should have clarified that 52 is after the first round of testing, not release. They are also classified, high, medium, low, with about 30% being low due to things like incorrect or necessary changes to requirements and only two high priority. [edit] As Electron Shepherd pointed out my calculations were flawed (I need a vacation). As a total it makes 57% which is very bad, but factoring out the low priority missing requirement defects lowers it a good deal and considering only two high priority defects it really isn't bad at all.
I know the language. I've read a book. - _Madmatt
modified on Friday, December 18, 2009 2:49 PM
Mark Nischalke wrote:
what is an acceptable, or expected, ratio of defects per lines of code
Frankly, I don't think this metric is useful in any way. There are many kinds of defects, ranging from data losses to misspelled comments, and line of code is not a very useful measure of program size.
-
I'm curious as to everyones view as to what is an acceptable, or expected, ratio of defects per lines of code. I know, it should be zero, but let's stick to reality. ;P I currently have a project with about 9000 LOC and 52 reported defects during initial testing. 173:1 or 0.006% I consider this good, but a manager is frustrated with the "high" number, the client has refused to start testing and most importantly, is withholding payment. [edit] I should have clarified that 52 is after the first round of testing, not release. They are also classified, high, medium, low, with about 30% being low due to things like incorrect or necessary changes to requirements and only two high priority. [edit] As Electron Shepherd pointed out my calculations were flawed (I need a vacation). As a total it makes 57% which is very bad, but factoring out the low priority missing requirement defects lowers it a good deal and considering only two high priority defects it really isn't bad at all.
I know the language. I've read a book. - _Madmatt
modified on Friday, December 18, 2009 2:49 PM
Here are the typical figures , (From Estimating Software Costs[^])
LOC (in thousands)
Errors/1000 LOC
< 2
0-25
2-16
0-40
16-64
0.5-50
64-512
2-70
>512
4-100
It is no brainer that, higher the LOC more the error ratio.
-
Hmm... Our metric is simply the number of bugs reported. It's not pro-rated with the number of lines of code. That said, our active bug list usually averages less than 100 bugs per product, and our products average 500,000 LOC. 52 defects in 9,000 lines of code does seem rather high. Do you classify your bugs? We typically have 'critical' (the world is coming to an end, i.e. the customer ain't paying), 'major' (someone's panties are in a bunch), 'minor' (Q.A. is pissed), and 'cosmetic' (somebody prefers pink). If you had say, 1 critical, 3 major, 20 minor, and 28 cosmetic, that's not bad. If it's more like 18 critical, 20 major, 4 minor, and 10 cosmetic, then you've got troubles.
Mark Nischalke wrote:
the client has refused to start acceptance testing
That obviously begs the question: if they aren't testing, then what are they basing their refusal on? An acceptance test either passes or fails. In either case, there are certain contractual obligations for both you and the client. If it passes, the client is supposed to complete payment on the contract. If it fails, you go back and fix things until it passes, or you and the client modify the terms of the acceptance test.
Software Zen:
delete this;Yes, breaking them down there are only two critical defects. The contractual aspects are of course beyond me. I wasn't privy to the details since I'm only doing the work, but this company is very immature and I'm sure didn't consider these things when signing the agreement with the client.
I know the language. I've read a book. - _Madmatt
-
I'm curious as to everyones view as to what is an acceptable, or expected, ratio of defects per lines of code. I know, it should be zero, but let's stick to reality. ;P I currently have a project with about 9000 LOC and 52 reported defects during initial testing. 173:1 or 0.006% I consider this good, but a manager is frustrated with the "high" number, the client has refused to start testing and most importantly, is withholding payment. [edit] I should have clarified that 52 is after the first round of testing, not release. They are also classified, high, medium, low, with about 30% being low due to things like incorrect or necessary changes to requirements and only two high priority. [edit] As Electron Shepherd pointed out my calculations were flawed (I need a vacation). As a total it makes 57% which is very bad, but factoring out the low priority missing requirement defects lowers it a good deal and considering only two high priority defects it really isn't bad at all.
I know the language. I've read a book. - _Madmatt
modified on Friday, December 18, 2009 2:49 PM
I've heard and read of people using this as a metric but it seems to me to be too big of a 'bucket' to really be meaningful. When I look at code quality, I tend to categorize defects based on severity and I dump all defects into a pareto chart based on the cause as well.
And above all things, never think that you're not good enough yourself. A man should never think that. My belief is that in life people will take you at your own reckoning. --Isaac Asimov Avoid the crowd. Do your own thinking independently. Be the chess player, not the chess piece. --Ralph Charell
-
Hmm... Our metric is simply the number of bugs reported. It's not pro-rated with the number of lines of code. That said, our active bug list usually averages less than 100 bugs per product, and our products average 500,000 LOC. 52 defects in 9,000 lines of code does seem rather high. Do you classify your bugs? We typically have 'critical' (the world is coming to an end, i.e. the customer ain't paying), 'major' (someone's panties are in a bunch), 'minor' (Q.A. is pissed), and 'cosmetic' (somebody prefers pink). If you had say, 1 critical, 3 major, 20 minor, and 28 cosmetic, that's not bad. If it's more like 18 critical, 20 major, 4 minor, and 10 cosmetic, then you've got troubles.
Mark Nischalke wrote:
the client has refused to start acceptance testing
That obviously begs the question: if they aren't testing, then what are they basing their refusal on? An acceptance test either passes or fails. In either case, there are certain contractual obligations for both you and the client. If it passes, the client is supposed to complete payment on the contract. If it fails, you go back and fix things until it passes, or you and the client modify the terms of the acceptance test.
Software Zen:
delete this;Gary Wheeler wrote:
52 defects in 9,000 lines of code does seem rather high.
I would say this is high. In a typical 75000 to 90000 line program that I write in a 12 to 18 months there better not be 52 detectable bugs when it hits production.
Gary Wheeler wrote:
Do you classify your bugs? We typically have 'critical' (the world is coming to an end, i.e. the customer ain't paying), 'major' (someone's panties are in a bunch), 'minor' (Q.A. is pissed), and 'cosmetic' (somebody prefers pink). If you had say, 1 critical, 3 major, 20 minor, and 28 cosmetic, that's not bad. If it's more like 18 critical, 20 major, 4 minor, and 10 cosmetic, then you've got troubles.
Very important what defects are classified as. On my average projects (ones where I am the only programmer) 0 or 1 critcal, 0 or 1 major, 0 to 3 minor and 2 to 10 cosmetic at the time it goes into production. Some of the minor and cosmetic are known at the time of production just that there was not enough time to fix or fixing them could break the design.
John
-
Gary Wheeler wrote:
52 defects in 9,000 lines of code does seem rather high.
I would say this is high. In a typical 75000 to 90000 line program that I write in a 12 to 18 months there better not be 52 detectable bugs when it hits production.
Gary Wheeler wrote:
Do you classify your bugs? We typically have 'critical' (the world is coming to an end, i.e. the customer ain't paying), 'major' (someone's panties are in a bunch), 'minor' (Q.A. is pissed), and 'cosmetic' (somebody prefers pink). If you had say, 1 critical, 3 major, 20 minor, and 28 cosmetic, that's not bad. If it's more like 18 critical, 20 major, 4 minor, and 10 cosmetic, then you've got troubles.
Very important what defects are classified as. On my average projects (ones where I am the only programmer) 0 or 1 critcal, 0 or 1 major, 0 to 3 minor and 2 to 10 cosmetic at the time it goes into production. Some of the minor and cosmetic are known at the time of production just that there was not enough time to fix or fixing them could break the design.
John
I should have clarified that 52 is after the first round of testing, not release. They were are also classified with about 30% being ones due to things like incorrect requirements.
I know the language. I've read a book. - _Madmatt
-
I should have clarified that 52 is after the first round of testing, not release. They were are also classified with about 30% being ones due to things like incorrect requirements.
I know the language. I've read a book. - _Madmatt
That makes a big difference as well. And incorrect requirements should not be the programmers fault. Although at times you do get blamed for not being able to guess what the actual required functionally is..
John
-
That makes a big difference as well. And incorrect requirements should not be the programmers fault. Although at times you do get blamed for not being able to guess what the actual required functionally is..
John
CIS 406: Reading the Mind of the Customer They offered that course after I graduated :laugh:
I know the language. I've read a book. - _Madmatt
-
I'm curious as to everyones view as to what is an acceptable, or expected, ratio of defects per lines of code. I know, it should be zero, but let's stick to reality. ;P I currently have a project with about 9000 LOC and 52 reported defects during initial testing. 173:1 or 0.006% I consider this good, but a manager is frustrated with the "high" number, the client has refused to start testing and most importantly, is withholding payment. [edit] I should have clarified that 52 is after the first round of testing, not release. They are also classified, high, medium, low, with about 30% being low due to things like incorrect or necessary changes to requirements and only two high priority. [edit] As Electron Shepherd pointed out my calculations were flawed (I need a vacation). As a total it makes 57% which is very bad, but factoring out the low priority missing requirement defects lowers it a good deal and considering only two high priority defects it really isn't bad at all.
I know the language. I've read a book. - _Madmatt
modified on Friday, December 18, 2009 2:49 PM
Defects are good. When I was with the State of Maine I told the Director to expect about 500 defects with the product when delivered. He was shocked. When the product was delivered and he started to see what a defect was, how they were fixed, and their importance he quickly became very happy. The bottom line is defects with Agile help deliver a quality application that MATCHES the client expectation. That said however, you mention your product is in Acceptance testing which means there should not be any defects, period. Acceptance comes after delivery. Your project should have had multiple beta deliveries planned so you could have identified and corrected those issues and shown a progressive track record of improving quality. Right now you are trying to deliver a product that is known to be defective. When I worked in the concrete industry shipping defective concrete was a no-no (if you get caught in QA you have to pay to redo the entire pour)
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
-
Depends on the size. We have an application that is close to 4MIL LOC, and reportedly close to 20k defects, roughly 0.005% defects. A lot of it is generated code, so I guess you could factor that out, and the DAL to bring it down to about 1MIL bringing it closer to your 0.02%, which is acceptable enough for names like Puma, so it should be acceptable enough for your client. But in your case, I'd say the magic number is the number that makes the comfortable enough to pay you :)
Check out the CodeProject forum Guidelines[^] The original soapbox 1.0 is back![^]
EliottA wrote:
4MIL LOC, and reportedly close to 20k defects, roughly 0.005% defects
Isn't that 0.5% ?
-
Defects are good. When I was with the State of Maine I told the Director to expect about 500 defects with the product when delivered. He was shocked. When the product was delivered and he started to see what a defect was, how they were fixed, and their importance he quickly became very happy. The bottom line is defects with Agile help deliver a quality application that MATCHES the client expectation. That said however, you mention your product is in Acceptance testing which means there should not be any defects, period. Acceptance comes after delivery. Your project should have had multiple beta deliveries planned so you could have identified and corrected those issues and shown a progressive track record of improving quality. Right now you are trying to deliver a product that is known to be defective. When I worked in the concrete industry shipping defective concrete was a no-no (if you get caught in QA you have to pay to redo the entire pour)
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
Ennis Ray Lynch, Jr. wrote:
ou mention your product is in Acceptance testing
No, I said they are refusing to even begin it. Whether the module has any reported defects or not.
Ennis Ray Lynch, Jr. wrote:
Your project should have had multiple beta deliveries planned
That's the point. It has, the customer hasn't done any of the tests though.
Ennis Ray Lynch, Jr. wrote:
When I worked in the concrete industry shipping defective concrete was a no-no (if you get caught in QA you have to pay to redo the entire pour)
Really not a good comparison IMO. Bad concrete causes structural failure that can cost lives. A software defect may only cause an incorrect total to be calculated, hardly on the same scale.
I know the language. I've read a book. - _Madmatt
-
EliottA wrote:
4MIL LOC, and reportedly close to 20k defects, roughly 0.005% defects
Isn't that 0.5% ?
Maybe, I might be extremely tired as it's the end of the day and close to a vacation. Right now, all inquiries are being placed in the 'I don't care to look at, address or resolve this until 2010' bin. Please place your inquiry there and I promise I will [never] get to it. Thank you.
Check out the CodeProject forum Guidelines[^] The original soapbox 1.0 is back![^]
-
I'm curious as to everyones view as to what is an acceptable, or expected, ratio of defects per lines of code. I know, it should be zero, but let's stick to reality. ;P I currently have a project with about 9000 LOC and 52 reported defects during initial testing. 173:1 or 0.006% I consider this good, but a manager is frustrated with the "high" number, the client has refused to start testing and most importantly, is withholding payment. [edit] I should have clarified that 52 is after the first round of testing, not release. They are also classified, high, medium, low, with about 30% being low due to things like incorrect or necessary changes to requirements and only two high priority. [edit] As Electron Shepherd pointed out my calculations were flawed (I need a vacation). As a total it makes 57% which is very bad, but factoring out the low priority missing requirement defects lowers it a good deal and considering only two high priority defects it really isn't bad at all.
I know the language. I've read a book. - _Madmatt
modified on Friday, December 18, 2009 2:49 PM
Mark Nischalke wrote:
9000 LOC and 52 reported defects during initial testing. 173:1 or 0.02%
173:1 is 0.57%, not 0.02%
Mark Nischalke wrote:
the client has refused to start testing
Not surprised. That ratio seems very high to me. Scaling up proportionally (and yes, I realise that's not a "scientifically valid" thing to do), our main product, that has about 400K LOC, would have over 2,300 defects. We wouldn't release anything outside of the development team with that defect level, and would never put it in front of a paying client.