Actually for QA Time Estimation we have to work and calculate a lot with lot of things like the previous post says. But that all things will never available in real life. If Project Manager asked for QA Time Estimation without any statistical data but just with Development time estimation, then we can follow the "general rule of thumb" that is 2/3 of the development estimate.
Remember, this will not be very accurate. But truthfully nothing is accurate in estimation, even for satellite lunching they may not have accurate plane.
In case dev estimated 66 days and for QA you can suggest 48 days, hopefully that won't cross then that. (4 days for backup). But still this estimation is just a lollypop to show not the real cake to eat…!!
Subscribe to:
Post Comments (Atom)
2 comments:
This holds good if we need to have a crude or rough estimation, even this was informative to reach Step 1, but from here I m hungry for more. I would love to see some stuff about how would you divide those estimated 48 days in to the various stages like writing TC, reviewing TC, executing TC and finally regression or bug fixing...
Looking forward to see them in your blog...
Yap, Nice Question.
But that all things are purly based on your project. Look at the previous diagram from IBM.Research. From that you can understand how to divide those estimation.
--Thanks for the comment Calex
Post a Comment