Jay,

It never ceases to amaze me what a small team of excited, motivated and intelligent individuals can accomplish in a very small amount of time.

Malcolm

>>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)?