As it has been said already, it depends but, going by development time does not tell you that much. Some guys can code a mile a minute while others are snails. Some do good unit testing while others don't do any.
My process is as follows:
1) Requirements documents. If available, I always estimate based on the requirements document. I outline my testing and estimate the areas to be tested, the number of cases and so on from this document.
2) I take in consideration past experience with the developer(s). How buggy their code has been. What has been their fix turnaround time.
3) Size of the development team vs my team.
4) Whether all code is in-house or are outside libraries used (new to us libraries).
5) How critical is this development. It is brand new product or an add on feature (most likely your case). How many and what other systems does it touch? Basicaly, do we have to regress of bunch of other stuff as well.
In either case, my estimate normally starts after the code has been tested/soaked for a week or so. Many times we find critical bugs the first week, fixes for which eat into testing time. In my group, my testing time does not start until we accept the code drop, which we will do after running a series of tests, i.e. soak time.
Hope this helps.