Estimating Testing Projects
Walkthrough on HowTo
The online content i have found regarding developing sound estimations for testing projects are found to be wanting in a lot of ways
- Articles start of promising and end up with “Software project estimation - Seat of the pants approach”.
- Articles packed with a lot of know-know but absolutely no how-to
- Articles that tell me how to keep doing what we are already doing.
Current Affairs
The current situation of software project estimation can be best described as CMM level 1 heroics. The nearest we conventionally come to it is a WAG (Wild Ass Guess). As to how this has become an acceptable practice in the software industry defies my comprehension!!?$!?!^@?!!! Sometimes people even go to the extent of categorizing this “exercise in futility” as a SWAG( Scientific Wild Ass Guess).
Bottomline: Doing a WAG or SWAG (Whatever you call it) is as good as doing no estimation at all.
What is an estimate?
An estimate serves as a masterplan for a software project covering all aspects like costing,staffing,timing. Hence basing this on pure guess work is a definite NO
Ok history apart lets get started……
Since this is a walkthrough on how to do an estimate we will start from scratch and move to the end…..
Please note that there are a lot of conventional things that we do which can remain as is. Lets concentrate on the flaws that haunt the practice.
1. Collectibles to start an estimate
Starting an estimation is back breaking work 
. There are the following elusive documents that one has to procure before sitting down to a sensible estimate.
1. Customer Requirements Specification
2. Request for proposal,
3. System specification/ Architecture.
4. Software Requirements Specification
I have often hear the following complaint, “Owwww but these don,t exist at that point”. The reply to that is that as per SDLC (Waterfall, Iterative, Jumbo circus whatever) models of software development these are the primary documents that need to be in place before we estimate for a project.
The necessity of having these document in hand is to prevent the wild ass from guessing about our project
2. Approaches to preparing QA estimates for a project
There are a lot of sound practices that people have been using to prepare development estimates like system lines of code (SLOC), use-case based analysis, function point analysis, object hierarchy trees etc.
In the following section i have proposed some of the techniques that can be used to prepare QA estimates for projects.
1. Begin estimation by conducting a comprehensive study of the system architecture, scope of work and the analyzing the complexity of work.
2. Determine what style of testing should be used in the strategy (you could chose from many options like use case based testing, scenario based testing, module hierarchy trees to name a few). This is a very important step which most QA personnel skip.
3. If you are adopting a module based testing, prepare a module hierarchy tree to visualize the inter-dependencies between modules.
4. Analyze and assign complexity to each node of this tree. Estimate the number of test cases in each module by analyzing the # of functionalities bundled in each module.
5. Ascertain by past experience or analysis, a realistic projection of QA productivity (no of test cases per person day). This is a metric which varies and WILL NOT FOLLOW ANY PRE-DEFINED ORGANIZATIONAL NORM.
6. Analyze each module to arrive at a preliminary idea of the extent of automation that is possible in each of these modules.
7. Estimate the strategy of automation in terms of how you will automate the testing, what will be the coverage of automation, what will be the complexity of developing automation scripts if any. ( a POC might be required for this at a later stage. This has to go into the estimate. Doing POC’s for software test automation is a severly neglected critical component of delivering QA processes.)
The above 7 steps have to necessarily completed and documented before you can start with the estimate.
3. Preparing the estimate
Identify the risks involved. These can range from technology risks, risks introduced by the delivery model that has been adopted and many other factors. Each risk identified has the potential of throwing your estimate haywire. Hence de-risking the project is an important part of estimation. In situation where the number of risks identified are high, it would be a good practice to prepare 2 separate estimates
- Conservative estimate: This will factor all the overruns in terms of effort, time and cost that would transpire if the risks realize themselves.
- Optimistic estimate: This will envision the delivery of the project if the risks identified do not materialize.
The benefit of having 2 versions of the estimate is that it would provide a clear cut picture of how bad things can go when risks materialize and what would be the losses incurred if the are let to remain.Conservative estimates can be projectional in nature where the increase in time, effort and cost can be show as a projection in relation to the risk.
The process of preparing the estimate start only once the above steps have been completed. All factors in the estimate have to be traceable to the documentation that has been prepared as part of section 2 of this document. The actual process of doing the estimate like assigning timelines and resource loading will be guided by the above section and help you arrive at a sound estimate.
The Golden rule of all estimations “DO NOT DO SOFTWARE PROJECT ESTIMATIONS WITHOUT ALL NECESSARY SUPPORT DOCUMENTATION IN PLACE.”
I have outlined only the measures to curb the flawed practices in the estimates. These could be incorporated to modify the existing process(if any) of preparing estimates within your organization. A complete walkthrough would expand the scope of this article exponentially 
For further insight into the implementation of such procedures at an organizational level you can contact me.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Related posts
Stumble it!
7 comments ↓
Thanks for sharing very important topic.
So if you are asked for an estimate without all the documentation, do you resort to a SWAG estimate?
Molly,
cos after all that is what it is wild ass guessing. Hence scientific is a misnomer.
There is nothing and can be nothing “scientific” about a Wild Ass Guess right?
The practice of doing estimations without supporting documentation is one of the industry worst practices which is deeply entrenched in some of the biggest CMM level 5 companies which i have worked with.
Since this is a common practice today, even your customers expect estimates for half baked projects & i know how frustrating it can be estimating such projects.
This is the bottomline, “The entire functionality or requirements of a proposed system have not yet been finalized to a good degree.” This means the customer is unclear about what he wants, then how would you clearly understand what he wants you to test.
Take a look around your organization:
1. if you see estimates going haywire
2. if you see project members working late into the night
3. if 2 months into a project you see work allocation happening by “seat of your pants method”
You can trace it to having set the wrong expectations during your estimation phase. It is the blueprint, never spoil it for lack of information. If that happens in your organization, its time for a “Process improvement proposal”
Ok, lemme answer your question…. “If you are asked for an estimate without supporting documentation, NEVER DO IT.”
“IS IT POSSIBLE TO REFUSE SOMETHING LIKE THAT?”……
Trust me i it is…. Been there done that
Lemme know if that answers your question
hApPy tEsTinG
Robin
yes, that does answer my question. Thanks a bunch!
The Golden rule of all estimations “DO NOT DO SOFTWARE PROJECT ESTIMATIONS WITH ALL NECESSARY SUPPORT DOCUMENTATION IN PLACE.”
Huh?
Thanks for the correction. sorry about the typo
Right now my company does 3 point estimates but there is nothing in place to verify those methods, like function points or something else. If function points dont really work then what would you recommend?
Leave a Comment