Estimating Test Effort
Posted: July 13, 2010 Filed under: Planning, Software Metrics, Tips and Tricks | Tags: Testing Leave a comment »One of the best known techniques are the ones provided by Caper Jones and David Longstreet. According to Caper Jones,
Total number of test cases = (Count of Function Points) raised to the power of 1.2.
David Longstreet provides a similar formula for computing the number of UAT test cases:
Total number of UAT test cases, which is = 1.2 x (Count of Function Points).
As with every such empirical model, one has to use them as a guide and evaluate them with real data. In my own experiences with web based (Microsoft dot net platform), the numbers are slightly different, and approximate better as follows:
Total Number of test cases = (Function Point Count) raised to the power 1.05
Total number of UAT test cases = 1.35 x (Function Point Count)
Once the count of the test cases has been found, apply the productivity factors for test case authoring and test case execution to arrive at the total testing effort.
The following is the data for a 3000 function point project on which the above formula have been tweaked.
Unit Test Cases : 13,000
Integration Test Cases : 5,000
System Test Cases : 13,000
UAT: : 4,100
Total : 35,100
References: Estimating Test Cases and Defects by David Longstreet
Software Estimation Rules of Thumb by Caper Jones (pdf)
When not to add resources to a project
Posted: May 4, 2009 Filed under: Planning Leave a comment »
Adding manpower to a late software project makes it later.
- Fred Brooks in The Mythical Man Month
My own two cents is that it is better to start the project with a higher team strength and then reduce it progressively rather than adding more resources later. In addition to facilitating knowledge acquisition up- front, it helps to separate the grain from the chaff and thus retain the right team members.
The key is to identify the points when the project ramp down should happen. That is what can make or break the project.
How to Convert Person Months to Calendar Months
Posted: May 3, 2009 Filed under: Planning | Tags: Estimation Leave a comment »Given that there is a project of 100 person months. In how many months can the project be realistically implemented?
Can the project be done in 10 months with 10 people? Can it be done in 5 months with 20 people? What if there were 100 developers….
COCOMO offers an empirical based formula to compute the optimal schedule. I haven’t had much success in using that. To be fair to COCOMO, it does have a number of parameters that can be tweaked. I did try but COCOMO seems to be on the far higher side even when I set the parameters to an unrealistic extreme. Instead, the following formula worked much better for my past projects that have ranged from 100 person months to 800 person months.
Number of Calendar months = 2.5 x (person months).33
So, for a 100 person months project, the calendar months = 2.5 x (100).33 = 11 person months
Based on your past experience, you can tweak this result, for me, it is adds 2 extra months. The optimal calendar months for a 100 person months project is 9 months after adjusting for the 2 extra months.
I cannot recollect from where I landed on this formula. Perhaps it was Barry Boehm’s Software Engineering Economics (1979) or more likely from Fred Brooks classic The Mythical Manmonth.
Update: I just looked up The Mythical Man Month. Fred Brooks quotes this formula from Barry Boehm’s Software Engineering Economics (page 274, Indian Edition, 2006).
