Making estimates on a test assignment is hard. What you include and exclude varies between each person. As I see it, there are many things to consider that might make the whole test effort longer and make it more complex. So, instead of guessing or giving a random number consider this…

When you are asked how much effort you need to spend on the various aspects of testing for a new feature it is quite common you picture yourself that …

• it is the person him-/herself who does the estimation that will perform the assignment/testing
• each assignment is done by just one person instead of the whole or part of the test team
• the test team have good cooperation with product managers, developers, other teams, other testers that are involved in the assignment, no obstacles at all here that will steal time
• all hardware is available and is fully usable from start
• all hardware will remain in perfect shape, nothing ever get broken, nothing ever need to be repaired
• all software is available and is in perfect shape
• test instruments, used in testing, are fully functional with latest revisions of hardware and software
• each tester in the test team has tip top domain knowledge and no education about the assignment is needed, there is nothing out there that is complex or hard to understand
• each tester in the test team is executing tests on the correct test object, no confusion about revisions or if parts of the test object is correct
• the computers in the test lab are so fast and powerful that everything goes smooth at all times, even the network is fast at all times
• performing each test goes fast without any faults found, everything works perfectly
• there is no need for assisting developers pinpoint bugs, since none will be found
• there is no need to verify bugs found, since none will be found
• there is no need for performing any kind of regression, we did the right thing from the start
• all documentation that is interesting for the testers is in such good state that nothing is unclear
• nothing outside the plan for the test team ever happens during the whole project, you are always on track on all things
• the test planning is so good that it is always on time without any delays
• there is no need for any meetings or discussions inside the test team or outside, administration of the assignment is not needed at all
• there are no conflicts in the test team, never have been and never will be
• the test team is constant in size
• no one will ever be sick, have kids, have to sleep, go to the toilet or  have lunch breaks
• the test team is perfectly aligned in how they should work with testing
• the test team is perfectly aligned with how the team is managed, no confusion or downtime
• all test automation works perfectly at all times, no disinformation at all
• automated tests never break and always report pass
• automated tests does not need to be tested since the developers never make any mistakes
• the test team will not introduce any new tools or ways of working ever
• everyone in the test team estimate the same way and has the same idea on how it should be done
• personnel that is going to assist the test team also loves testing and will have no issues at all being removed from their previous position, it won’t affect their work at all
• personnel that is going to assist the test team will always bring joy and happiness to the current test team, there will be no conflicts ever
• utterly new personnel has full knowledge of corporate culture, where to get information, who does what and when, what is expected of them
• utterly new personel who stays for three weeks will be productive the whole time
• utterly new personnel never need anyone to mentor them or introduce them to assignments

… and you have not even gotten to the actual testing or test planning part.

I know… if you think like this will you ever get any assignment? Perhaps it is just better to give the amount of time that your stake holder want to hear? Still, I think that if you identify things that steal time from testing or make the assignment take a longer time, there is a big chance that management might be able to assist with removing these obstacles or see that you have thought this through.

Further reading related to test estimation:

http://blogs.msdn.com/testing123/archive/2007/04/11/demystifying-test-estimate.aspx

http://blogs.msdn.com/alanpa/archive/2007/03/13/test-guesstimation.aspx

http://www.developsense.com/blog/2009/11/why-is-testing-taking-so-long-part-1/

http://www.developsense.com/blog/2009/11/what-does-testing-take-so-long-part-2/

http://www.developsense.com/blog/2009/10/when-do-we-stop-testing-one-more-sure/

http://www.silverpath.com/resources/Silverpath-EstimatingTestEffortWhitepaper-080812.pdf

http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=8918&tth=DYN&tt=siteemail&iDyn=2

http://inderpsingh.blogspot.com/2010/03/how-to-estimate-testing-efforts-6.html

http://www.satisfice.com/blog/archives/124

and an infinite amount of good books on testing where most of them touch the test estimation subject.

What do we actually base our time estimations on when delivering a plan to a project manager?

I know that we initially can have a vague idea on what to include and what must be done. I am sure that we can even make a rough estimation on how many resources we need in some cases. If we are testing something new, where we do not know the developers and the full extent of what is delivered, how do we know how much time and resources we need for testing? I have seen many plans that give an estimate, but how accurate can they be?

Once I did a resource plan for a year long test project, I was allowed to change the plan incrementally. I estimated that we needed quite many testers since the deliverables had been delayed and the original plan with incremental builds early did not work out as planned. In the test team we had a few disagreements about how many we actually needed, some thought that we were enough and some (including me) thought we needed more. We got 10% of the resources that I had wanted, but we managed somehow (to some extent). Decision makers seemed to be satisfied with the quality and the result of these tests. One of the reason for us succeeding was that we reported more bugs than the developers were able to fix. If we would have been more testers we would have found many more bugs for sure, but they would probably just have been postponed. The most critical ones were always fixed, but all others below that could not be fixed naturally.

So… should we when estimating resources and time focus on getting enough and the right resources just to keep the spot light of the resource discussion somewhere else? Lets say that bugs are fixed faster than we find new ones, will that mean that we are ready to deliver or that we need more testers to find even more bugs?

I think resource planning and time estimations is very hard. Michael Bolton has expressed, in an excellent way, many of the thoughts that I have tangled with. You can find his reasoning here:
http://www.developsense.com/2009/11/why-is-testing-taking-so-long-part-1.html
http://www.developsense.com/2009/11/what-does-testing-take-so-long-part-2.html

Combine the idea of having estimated how long time testing needs with an answer on how far we have come and especially pinning it down in percentage. Can we say anything truthfully here? Is it worth the cost it takes in planning and administration to give a accurate picture?