I have not followed any effort estimation techniques to provide the estimations for completing the design of test...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
cases and the duration required by the team of 4 members to complete the testing cycle. Could you please explain to me how managers or leads provide the estimation for completing these tasks?
Estimates can be difficult; one reason estimates can be so challenging is that estimates are often requested so early in a project that you might not know enough information to provide a close to accurate estimate.
Here's one approach: Break each large task down into smaller tasks. When I reference small, I'm thinking nothing larger than a week or about 30 hours of work. The smaller the task you're estimating, the more likely you are to be on target. Before you finish estimating at the low level, consider how much time you might need if everything doesn't go smoothly. Build buffer time. Since you might not need to show all the estimates and the breakdown you've created, roll the estimates back up into the categories requested. If you get asked for details, you'll have the breakdown of how you came up with the higher level estimates. Resist the urge to shave or reduce the estimates when you roll up. Sometimes if the number looks too large, you might doubt yourself or be tempted to start cutting.
A suggestion I'd like to offer is -- ask the people on your team for input. If you're the test lead or test manager, ask the people on your team who'll be doing the work what they think. I often write estimates and then hold onto what I think and ask people on my team for input. When they provide their estimates, I share what I have created. I do this so that they're not swayed by what I have written. And I'm happy to talk through estimates with the people on my team. When we talk out estimates, it helps us understand the work better and to anticipate issues that might drain time during the actual work.
And finally there is an old rule of thumb that testing will take about 30% of development efforts. I don't like this rule of thumb as a blanket statement because I think sometimes functionality can be coded faster than the same functionality can be tested. And in other cases, testing can take less than that time. There are variables in estimates I like to consider as well -- like compatibility testing that might not be factored into a quick 30% rule.
If at all possible, keep a history of your estimates versus actual. Time and experience are some of the best educators. If you keep track, you might gain useful history.
Dig Deeper on Software Test Design and Planning
Related Q&A from Karen N. Johnson
There are so many resources out there about the ever-changing world of Web design and mobile testing, but to choose the most salient and insightful ...continue reading
In this expert response, consultant Karen Johnson describes strategies she uses for browser compatibility testing. Experience and knowledge of common...continue reading
Initiating test automation on your project team may seem challenging, or even overwhelming. Fortunately, expert Karen Johnson has been through this ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.