I just read a post from Shrini on test estimation, and it triggered a thought that was tangential enough that I thought it made sense to try to capture it here rather than as a reply to Shrini.
Numerous writings exist on estimation for programmers / developers, and many testers have similarly written about test estimation. I think that the fundamental problem with "test estimation" is that it shouldn't exist - at least in isolation from other estimations.
The problem is that test estimation models need to be largely based on the development estimation models they are coupled with. For example, if a development team writes crappy code and gives it to the test team as soon as it compiles so they can "test the bugs out of it", the development estimation times will be low, but the test estimation times will be relatively high. On the other hand, if the development team unit tests the heck out of their code, and are diligent running static analysis tools and in code review, the test estimate may be lower.
The answer, of course, is that there should be one estimate. What is the estimate to be "done". The teams that use scrum correctly already know this. They estimate when a component, feature, or product will be "done", and they carefully define "done" to include both development and testing activities. Frankly, I don't see how else you can estimate accurately without defining "done" regardless of your development approach.
How common is this scenario (probably not too hard for most of you):
Manager: Bob - how long will it take you to code this feature? Bob: 'bout two weeks. Manager: Great. Frank - how long will it take to test? Frank: Two weeks sounds good Manager: Nah, you can do it in one. -- 3 weeks pass -- Manager: Frank - are you done testing yet? Frank: Not even close. Bob checked in his code on time, but it was barely working, and I've spent most of the last week blocked while Bob is fixing the first 50 bugs I sent him.
Manager: Bob - how long will it take you to code this feature?
Bob: 'bout two weeks.
Manager: Great. Frank - how long will it take to test?
Frank: Two weeks sounds good
Manager: Nah, you can do it in one.
-- 3 weeks pass --
Manager: Frank - are you done testing yet?
Frank: Not even close. Bob checked in his code on time, but it was barely working, and I've spent most of the last week blocked while Bob is fixing the first 50 bugs I sent him.
Rather than an estimate of 2 weeks for development, and 1 week for testing, this component could have had an estimate of 3 weeks to "done"++, and Frank and Bob should work together to both come up with that estimate and deliver on time or adjust the initial estimate. Otherwise, Bob won't consider testing implications or code quality in his estimates, and without that knowledge, Frank's estimate is nothing more than a SWAG.
I'll go out on a limb and say this: Stop doing test estimations. They're nothing more than guesses used to put buffer into the schedule**. Instead, estimate how long it will take for implementation and testing combined, then have testers and developers work together to deliver on time.
++ Note that scrum (done correctly) would encourage breaking this estimate down into pieces no longer than 2 days.
** There will inevitably be some time set aside in the schedule for integration and acceptance testing. My comment above is in regards to feature or component estimates.