Estimating QA hours for the stabilization cycle of a project or release is extremely difficult. I attempt to view several factors when conducting my estimations. 

The first item to examine is the complexity of the functionality being tested.  This is tough to measure in my opinion.  Normally experience plays a huge role in estimating the complexity.  I also use attempt to estimate each test case and a lot a block of time for exploratory testing.  In my development environment there are a ton of changes to the requirements.  We work in an agile type environment and the requirements are constantly in flux and it is important for the team to work closely to ensure we are developing and testing the correct product.  This flexibility tacks on an added complexity when attempting to measure complexity!!  I know that was not funny but it has been a long day……

The second item which is examined when estimating stabilization hours is the regression testing timeframe. I always add this to the end because usually we don't find many errors in the full regression testing but we cannot rely on the system testing alone.  It can also be devastating to make it almost all the way through regression only to find a costly error. 

At the end of the day it is still difficult to get a dead on estimation of hours to fulfill the project.  The goal is to provide a product which is Fit for Use and if it takes a few more hours to do that than so be it. Although I am going to continue to refine our process and even try to determine a way to prove statistically how long each complexity of item takes to produce.