One of the most difficult and critical activities in IT is the estimation process. I believe that it occurs because when we say that one project will be accomplished in such time by at such cost, it must happen. If it does not happen, several things may follow: from peers comments and senior management셲 warnings to being fired depending on the reasons and seriousness of the failure.

Here are a few rules for effective testing estimation:

Rule 1: Estimation shall be always based on the software requirements
All estimation should be based on what would be tested, i.e., the software requirements.
In many cases, the software requirements are only established by the development team without any or just a little participation from the testing team. After the specification have been established and the project costs and duration have been estimated, the development team asks how long would take for testing the solution.

Instead of this:
The software requirements shall be read and understood by the testing team, too. Without the testing participation, no serious estimation can be considered.

Rule 2: Estimation shall be based on expert judgment
Before estimating, the testing team classifies the requirements in the following categories:
- Critical: The development team has little knowledge in how to implement it;
- High: The development team has good knowledge in how to implement it but it is not an easy task;
- Normal: The development team has good knowledge in how to implement.

The experts in each requirement should say how long it would take for testing them. The categories would help the experts in estimating the effort for testing the requirements.

Rule 3: Estimation shall be based on previous projects
All estimation should be based on previous projects. If a new project has similar requirements from a previous one, the estimation is based on that project.

Rule 4: Estimation shall be recorded
All decisions should be recorded. It is very important because if requirements change for any reason, the records would help the testing team to estimate again. The testing team would not need to return for all steps and take the same decisions again. Sometimes, it is an opportunity to adjust the estimation made earlier.

Rule 5: Estimation shall be supported by tools
Tools (e.g a spreadsheet containing metrics) that help to reach the estimation quickly should be used. In this case, the spreadsheet calculates automatically the costs and duration for each testing phase.
Also, a document containing sections such as: cost table, risks, and free notes should be created. This letter should be sent to the customer. It also shows the different options for testing that can help the customer decide which kind of test he needs.

Rule 6: Estimation shall always be verified
Finally, all estimation should be verified. Another spreadsheet can be created for recording the estimations. The estimation is compared to the previous ones recorded in a spreadsheet to see if they have similar trend. If the estimation has any deviation from the recorded ones, then a re-estimation should be made.
Share
Related Documents
  1. Testing Estimate process (1504)
  2. Factors Affecting Software Test Estimation, and General Tips to Estimate Accurately (2823)
  3. How to do the estimation in testing? (3173)
  4. Software Testing Metrics (2760)
  5. 8-Step Metrics Program: An Introduction to Metrics (1892)
  6. Software Testing Time Estimation (1542)
  7. How to Estimate for Software Testing at Proposal Level? (2466)
  8. Questions for Better Software Estimates & Plans (1404)
  9. Test Estimation Techniques (4828)
  10. Test Estimation Process (2164)
  11. Estimation for testing on a new software project? (1330)
  12. Software Project Estimation Model (2627)
  13. [Ebook] Software Development Cost Estimating Guidebook (4601)
  14. Testing Project Estimation Guideline (2845)
  15. Size of software in IFPUG Function Points (2820)
  16. Selecting Measurement for Software Project (1589)
  17. Software Test Estimation - 9 General Tips on How to Estimate Testing Time Accurately (2257)
  18. Project Performance Measurement (1635)
  19. Test effort estimation (1655)
  20. Test Estimation technique (3925)