This is really easy and good to understand ...
here is this for u all...
Estimating Testing Projects
Walkthrough on How-To
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……
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
Thankfully From : http://www.testinglounge.com/2007/06/12/qa-estimation/
By :Robin Thomas
No comments:
Post a Comment