Let's start with a story first:

I recently got quite busy trying to get estimates done for a new project release.  There were demands placed by estimator- give us system architecture design document, give us plan, give us risk, give us objectives.....

We tend to ask a lot and not do much with what we have. Just like what goes between God and  supplicant. Anyway there was this 5 pages performance testing questionnaire and multiple rounds of internal iteration about what should be asked and what should not be before we sent out the questionnaire. The end product of our sophisticated estimation methodology was that client asked for bare minimal performance testing. Since we can not keep fraction of a body for work we kept one whole person for the job for the duration of project.

And let's move on to sophisticated estimation methodology. Not sure how many of the readers have attended parties in Northern India but there is a system of pricing per plate. So if you are hosting a party of 200 then ask for about 225 plates and with per plate cost of 'x' your price for hosting the party with food, music, decoration, rest areas etc cost 225X. The point I use to ask my dad was that why can't we take our own plates and then it will be sort of helping our hosts as well. So if all guests could get their own plates basically our host could do the party for free.  Now plates were chosen as a unit because it was assumed that everything was in  proportion to the number of plates and more the plates, i.e. the people the more are  likely to be the costs to the service  provider and more importantly, more likely is the person to pay up because he/she understands, more the people invited greater will be the cost.

Now we end up looking for similar 'plates' in testing or any other software estimation. It is all fine as we do happen to count plates correctly. The problem is with following-

a. Assuming everything being proportional to plates. So if we have 'X' number of test cases then the testing estimate is 'XY' where it takes 'Y' person days per test cases.

b. The value 'Y' is very presumptuous. Doesn't go through same scrutiny as does figure X.

For three reasons estimations are unreliable.

 I will follow three approaches- software, human and spiritual. Let's start with latter first.

Spiritual argument: We don't know ourselves, what all we do and why we do what we do. That further diminishes our chances of correctly understanding others. That means ours and everyone's  productivity cannot be ascertained. If we can't ascertain productivity then we can't get the timeline right.

Software argument:  a. Testing budget and timelines are decided before we start estimations and they rarely get changed due to our findings.  Also no one can predict the quality of code. More the buggy the code more time will be spent in testing & fixing & testing. Basically 'plates' are on development side.

b. Another flaw in the approach is that we estimate for what we can, which is typically about 50% of the project and do nothing about remaining tasks such as planning, report making,  defect fix support etc. In one test automation estimation I did only 30% of budget was allocated for engineers during preoductive period of writing code. That is what we focussed at. We didn't focus at engineers during planning and design phase and we didn't see what leads and managers were doing during construction phase.

c. Then there is this forgotten aspect that planning means applying foresight. It's often taken to be littering a document with so many numbers and graphs that one is inspired to believe the numbers mentioned in summary page of the document.

Human argument: Human being being don't have the capacity to deal with details unless it comes to their personal lives. That level of life long intimacy is required. Most hardly feel for their projects. Even a mother does not remember to put all things in the diaper bag despite best of the intentions. Also there is general frowning for detailed approach. If you ask a lot of questions and that will not make you very popular. It will give the impression - a. You don't know anything b. You are trying to show other person down or c. You are a conversation addict or plain and simple insane. 

The solution: We still need to do estimation and if our findings indicate serious need for resource intensive testing then ask for more resource. Normal estimation includes counting test cases and multiplying with a number to get count. That does not consider quality risks and requirements. So do the plate count but count other things as well and garnish with  with findings from previous projects. Don't shy away from details. All visionaries have a paid a price for being alive, be prepared to do the same. Look at history.  Some child will get to be more with their parents for the work you do. That should be an incentive enough.