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).
4 Answers
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.
Also consider:
- 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?
http://strazzere.blogspot.com/2010/04/what-is-correct-ratio-of-development.html
-
1Hello Joe, Whenever i feel that i still new informations & thoughts on certain testing concepts, i always never fail to visit ur blog. But somehow i missed this post. I was expecting just answers, but i got more than i expected. ie. examples you mentioned. Thanks for time and the web link. Aug 11, 2011 at 12:43
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.
-
+1 Good examples! A few other factors are how buggy the code from the devs is, how easy it is to fix bugs (how well the code was designed), how early stable requirements are available to test, how experienced the testers are, and how much automation is used to reduce the tester's burden after release to test. Aug 11, 2011 at 21:35
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.
-
Oh, you're lucky! The formula where I am is 20%... Unless automation is happening, then it's 40%. Needless to say, we're always somewhat pressed for time.– Kate Paulk ♦Aug 11, 2011 at 12:45
-
Actually, the team that I currently work on has no problems giving 1:1 or sometimes greater. We've been bitten by poor quality in the past, and spend the extra time to try to ensure that we always deliver nothing but the best. Aug 12, 2011 at 1:42
-
Lyndon, that's great. It's always heartening to hear that there are places who really do give more than lip service to quality, and don't fall into the trap of letting external pressures dictate when a release goes out. It's all very well to promise a customer that you'll have feature X to them on date Y, but to deliver it half-baked always leaves me with a bad taste in my mouth.– Kate Paulk ♦Aug 12, 2011 at 10:40
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.