Thursday, 27 March 2008

Test Estimation, take a step back

As test professionals we're expected to answer 'off the cuff' how long something will take to test. It must be the single most common dreaded moment for any test lead or manager. The projects starting and we're expected to know ho long all test tasks will take, including the identification, authoring and execution of tests. Sadly, 'How long is a piece of string...' doesn't go down well nor does sarcasm about how it's pointless estimating because after the project owner/customer/developers delay/change/fail to write documents, etc. the estimate will be worth poop. As true as it might be.

So, these 'challenges' aside how can the test professional at least arrive at a reasonable set of estimations for the test tasks? Firstly we need to know what tasks are needed. It's seems right that we should be able to break down a delivery of testing into a set of known or expected tasks. Having those identified we could then estimate how long each would take.

Taking a step back - it's essential that the test manager is clear on what tasks should be performed for a given project. That comes through designing a test methodology or several which can be applied to various project types.

A further step is to model the effort needed to deliver each task. For example, writing the Test Plan. Though it's impossible to estimate with perfect accuracy the test manager cannot make this up every time. They must have 'model' answers that can be refined in context of the project.
When I get folks who are convinced they can't possibly say how long I ask: 'How long does it take to write a test plan?' - 1 month? 1 hour? Well no. 1 week then? Too much. With all reviews, maybe 1 week start to end. The effort for this? By the test manager maybe 2 days tops. Great, so my model answer is a Test Plan takes 1 week to deliver and requires 2 days of effort by the test manager.

Test Case identification and authoring is more difficult as the complexity and number of cases needed is entirely context dependent. There's a greater reliance here on the project being run in a way that delvers such artefacts as good requirements documents. Ah yes, back to that old chestnut.

Next time I get a project I'll think about it's complexity, the competency of staff, etc. and provide a duration/effort in context of the project. But I have my model answer as a start point so I can arrive at reasonable estimation more quickly. Rinse and repeat for every other task in your methodology and you have a general estimation model(s).

0 comments: