Generally when pressed I always estimate testing effort including re-testing to be the same duration as development.
So if a piece of code/functionality takes 2 hours to complete, I usually say it will take 2 hours to test. This ensures I have enough fat built in. This also depends on how much unit testing has been performed, the complexity of the code and the experience/skill of the developer including the testing cycle iteration that you are in, the further along you are on the testing cycle the less time it should take to test a piece as most of the issues should get ironed out as the project progresses. There will come a time when the amount of testing required will remain constant which in my experience has been about 50% of original development time to be assured of risk assessment.
e.g For the 2 hours development, I would initially estimate 2 hours testing, but towards the end of the project or test cycle (after the first couple of passes), if any regression/testing reiterations have to be conducted, you may find that the minimum time on this piece would be 1 hour no matter how big the change is to this 2 hour dev component. 50% has always been the minimum rule I apply.
Itemising pieces of work will aid in estimation. I have found that in most when combining time to create the testing framework and conducting the time usually equates to 50%-100% of initial dev time.
This includes
- Use case/checklist creation, investigation and documentation
- Use case checklist testing and review
- Test execution and retesting bug fixes
This rough rule has always worked for me for over 30 or so projects.
Note – If you have historical data of previous testing efforts that you can base your estimates on the more accurate your estimates can be.
Note 2 – Test estimations should not include release management and the time it takes to release into environments including smoke-testing.
