Torpedoes for Your Estimate

I just revised my standard boilerplate text for my estimates that describes what factors and known unknowns can effectively render the estimate meaningless. Here it is:

The estimate might fall short of actual testing effort necessary due to the following factors:

  • The tester finds a large number of defects. Running test cases is very straightforward. However, discovering issues requires the tester to: return the application to the preceding state; run the test case again to recreate the issue; capture the screenshot of the application state during the issue; and log the issue in the defect tracker. Additionally, time to retest these additional defects adds to the total test effort.
  • The tester finds defects behind functionality behind functionality previously blocked by a defect. Sometimes defects prevent a tester from completing a test case; when the initial defect is corrected, further behavior on the test case path will uncover other defects.
  • The application includes new functionality or hidden complexity. This estimate is provided based on the software demonstration provided. Any additional functionality or application complexity discovered after the completion of the demo might require a greater number of test cases and test effort than anticipated.
  • The application is deployed/built a limited number of times. Each additional build requires a number of tests to check the application state (often called a sanity test or a smoke test). As the number of deployments or builds grows, the test effort grows with them.

So what else torpedoes your estimates?

Comments are closed.


wordpress visitors