Some say that testing hours should be less than development hours when estimating a development project. But I don't fully agree with this. (take an example of web application with shopping cart).
There's no inherent preset relationship between development time and testing time. And there's no inherent preset relationship between development/test staff ratio, and development/test time ratio.
The time required to test something is contextual - it depends on factors that may have little or nothing to do with how long it took to develop that feature.
- what counts as Development?
- what counts as Testing?
- If we were going to perform regression testing anyway, does that count as "zero" additional testing hours?
As Joe and Lyndon have said, it depends.
Some of the factors that impact how much test time will be needed relative to development time are:
- Is the development a green fields project or can the changes potentially affect legacy functions? In the case of the latter, there's a lot more testing time needed than the former.
- Are there regulatory requirements attached to the development? In my workplace, tax compliance and PCI compliance are big issues. Test time for these often exceeds development time.
- What are the costs of application failure? As a general rule, there'll be more testing needed for anything that's going to have major costs of failure. A new website that crashes the browser isn't going to have the same cost of failure as say, a Facebook upgrade crashing the browser. If the development involves aircraft software or medical software, expect very high testing time requirements.
- How much developer testing is there? I've found that testing load for development in an agile, test-driven setting is much lower and usually much more exploratory than for more traditional environments.
- How much is changing? Right now I'm spending massive amounts of time in testing due to a development environment upgrade which also required that every third party component be upgraded and much of the oldest code in the application (some of it over 20 years old and grandfathered in because of the high refactor risk and time required) to be refactored. The time cost for this may not exceed development time - but that will largely be because there won't be time to thoroughly test everything. Ideally for this case test time would exceed development time.
Those are just a few factors that can affect the balance between development and testing time, and one of the reasons I detest the formula approach.
I seem to remember a great blog post about this a few years ago. I just wish I could remember who it was by or where it was.
Typically, testing time is less than development time. A lot of people say 30-40% of development time, but personally, whenever I've received only this much time, I typically feel as though I haven't done as much I should have. The actual time will always vary. Sometimes it ends up being much more than development time. This will also vary greatly depending on the approach that's been taken by the development team as a whole (including testers). If you're on a traditional project, testing time is going to be longer. On agile teams, I've found my testing time to be significantly shorter.
In the end, the answer is, it depends.
10% to 60% - based on Gilb's book Software Inspection. The book says that you can reduce development time by 30% to 50% with formal QA. The book claims that testing/QA consumes over 50% of development time if you have a low ROI QA processes. The book has a lot of numbers and cites sources for the claims made.
The 10% above, is a personal estimate after years of collecting numbers and trying to improve the ROI of QA (sorry I don't have anything better). Gilb suggest about 1 hour per A4 sheet.
Project complexity also has an impact. Gilb suggests estimating project complexity.