The real strategy in estimation would be
- Need to get the requirement, design specs as early as possible
- Break down the tests into a skeleton as much as possible
- Identify the variables – such as the builds, quality of code and severity – build a consensus and understanding between all parties (PM, Dev and Test)
- Identify the resource and have them ready before the test starts
- Prototyping the smallest denominator in API, Web UI, and manual test cases. Use the number as a basis for all future test cases development.
- Use test plan and test matrix to determine the priority for the repeats required for configuration, builds, regressions, hot fixes.
- Average out the non-project tasks by calendar. Assumes for the worst for the sick leaves and vacations delays.
- Use the past practice to determine the administration overhead as to the meeting, training etc.
- Determine the commitment level of the contribution to non-project activities such as community board participation.
- Determine the commitment level of code review, design review, doc reviews for the project.
- Leave buffer time for unexpected events
- Have constant communications with PM and Dev to know the status of uncontrollable tasks.
- Machine resource and people resource need to be considered. If the test requires 10 man weeks. It does not mean two men will take five weeks only. It is most likely to take 7 weeks as the communication overhead will increase.
- Prepare for the worst by leaving some buffer – 10% if you can for the unexpected.