>Jay,
>
>Thanks for sharing. I think what of the factors that will have an important bearing on ratios is whether or not an application is an in-house application or an application being distributed to 3rd parties (such as vertical market apps).
>
>It would make sense(?) to me that there more testing resources would need to be invested for testing distributed vs. in-house software.
>
>As an aside, the more I reflect on the topic, the more I think that testing and documentation need to be more holistically integrated into the development cycle vs. treated as seperate phases. (My 'Extreme Programming' philosphies raising their nasty little head)

I'd agree with you. When we run into a function that has caused problems in the past (assigning security rights is one very current issue), I meet with our technical writer and a member of the QA department and develop specs right there -- information design, interface behavior, etc. As we come to a reasonable place, I document what we've come up with, identify limitations and justify the tradeoffs made. When we have buy-in from the 3 areas, it makes it much simpler to develop something that we can all live with.

Our staff has decades of expertise in the area. We rely on that expertise in lieu of a complete written specification. And, that would probably not be cost-effective with the price points in our industry. But, addressing hot spots like that gives us a more formal process to generate specs at the needed time.


Jay

>
>Regards,
>Malcolm
>
>
>>Fred and Malcolm,
>>
>>For our vertical market app, we have the following ratios of staff, and everyone's pretty consistently busy without lag times:
>>Developer -- 60%
>>QA -- 26%
>>Documentation -- 14%
>>
>>
>> Jay
>>
>>>Fred,
>>>
>>>For some great thoughts on testing and integrating testing into your programming efforts 'holistically' vs. formalizing testing as a seperate and independent phase of development, read up on Extreme Programming.
>>>
>>>For a good start there's www.extremeprogramming.org.
>>>
>>>And/or go to Amazon and search on the topic 'Extreme Programming' and read the reviews.
>>>
>>>Although not a book about testing per se, the work 'The Mythical Man Month' is a classic for analyzing ratios and estimating time lines. Worth reading in and of itself.
>>>
>>>The above advice aside, my experience on working on large software projects at big corporations is the following:
>>>
>>>- Testing budgeted at 10-15% of project effort
>>>- Time required for actual testing - 25-40% of project effort
>>>
>>>Good topic - I'm interested in following this thread.
>>>
>>>Regards,
>>>Malcolm
>>>
>>>
>>>>>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)?