Fred --

Your situation reminds me of a story. A friend of mine once said to a car salesman who was pressuring him, "I am the customer."

Since the issue of testing is a service you're purchasing, the resources I mentioned are probably not that relevant. But, I thought I'd mention them more specifically anyway in case you need some ammunition.

Boehm developed his notion of software economics based on the LOC (lines of code) measure of development performance. Even though LOC has more relevance to COBOL than other languages, the value is still debated in those circles. He has probably 10 pages in Sofware Engineering Economics devoted to error generation and correction. Highly statistically oriented. Not much help on analyzing the cause of bugs or remedies. Except that the earlier you catch the bug, the less expensive it is to correct.

Jones based his work on FPA (function point analysis) which maps better to environments we work in. There are weighted values for tables and their sizes, forms and their complexity, algorithms and their complexity, etc. In _Applied Software Management_ he devotes half the book to defect measurement, analysis and remedies.

His _Assessment and Control of Software Risks_ uses the "medical" approach. More up-to-date than ASM, it has a lot of valuable information regarding software quality and is worthwhile consulting to get a handle on the issues and costs involved in a more concise way than the previous book.

He devotes a whole chapter to defect analysis in volume 1 of his series _Quality Software Management: Systems Thinking_. He analyzes and articulates well methods of determining why a team is generating errors at an undesireable level, though this is more oriented towards project management.


I remember one story about one approach, I believe called Zero Defect Software. It sounds pretty reasonable until you get to the line that says: Never let developers compile their code! All defect testing was to be performed by testers.

A friend of mine worked in a location using ZDS. As you can imagine, that approach introduced a tremendous lag time for fixing the simplest of problems like misspelled variable names. Development crawled to a halt.

So, my friend brought in a compiler. People couldn't believe the quality of code that he was producing! Folks thought he hung the moon. Until management discovered the compiler on his system. He was promptly fired!

Jay



>Thanx for the info.
>
>It's my new job that has brought up these issues. I have an issue with the consulting company we are using lumping all of their testing into one general category. They have a testing department and it spends about 8 times the number of hours testing the application than the single programmer spent on it. The develper doesn't break his hours out either so there is no telling what his ratio of testing to development is.
>
>
>
>>>>Is a general estimate of the ratio of programming time to testing time?
>>>
>>>Let's try this in English.
>>>
>>>Are there any general rules or guide lines covering the amount of testing time in regards to development time (actual programming hours)?
>>