I have not followed any effort estimation techniques to provide the estimations for completing the design of test 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 Topics Archive
Related Q&A from Karen N. Johnson
User acceptance testing and system integration testing differ in one key way: the person who does the testing. Learn when to apply UAT vs. SIT. Continue Reading
Database testing can refer to any backend or data-related testing such as data migrations and data integrity. In this expert response, Karen Johnson ... Continue Reading
Understanding the nuances between different types of test efforts can be a challenge. In this expert response, Karen Johnson explains what is meant ... Continue Reading