To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
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.
|
