Header Ads

Test Effort Estimation

Test Effort Estimation :
This is one of the area where experience plays a vital role. Generally people who understand business better does that. This is nothing but to estimate your labor and non labor costs.
The factors that influence the effort estimation are nature of the work and the people on the project. It is necessary to understand how realistic and actionable the project is, how reliable and safe the test environment is and correct execution of early test results. It would be a good idea to see if the current project matched with any previous one so that documentation and test systems can be reused.

Again,Application size is one of the important factors to be considered for effort estimate. Obviously small applications will need small effort whereas large applications will take high effort for testing.Generally judgement is required to understand how big is the application.
for a test manager effort estimation is
There are 3 steps of effort estimation.
1. High level--used by Business developper or Finance persons
2. Mid Level-- Used by Managers to determine the costs and progress
3. Lower Level--Used by team lead and members
Typically
High Level estimation=Sum of mid level estimation+buffer time
mid level estimation=Sum of Lower level+buffer time
High Level Estimation is driven by customer and pricing of a company. Even it is also dependent on the pricing of a rival company as well. Generally in thsi phase people do not know about the actual picture or requirements.So they follow the industry standard of 40% of development activity will be testing activity.
So if you really go down the estimation level the more accurate and detailed estimation you will get. So the ROM(Rough Order of Magnitude) continues to become tough while going downline.
There are many techniques to do effort estimation. They are
1.task decomposition (Work Breakdown Structure)
2.expert opinion
3.analogy
4.Pert
5.Milestone
6.PCM
The task decomposition is the most effective for software testing.The software testing can be decomposed..
1.test design
2.test case creation
3.test case automation
4.test case execution
5.test analysis
6.defect tracking
7.test reporting
8.test bed preparation etc.
Now its time to assign time to the decomposed tasks as per the above written list and assign time. This has to be done very carefully. What i prefer is to add buffer here as well.In day to day life our project plan overlook the requirement change which is not a "Change Requirement" or a Rework needs to be done.Buffer will support these activities.
There is Contingency or risk needs to be estimated as well.
Now write down all the assumption clearly while hand it over for a expert review.This is tell the does and donts to the fund manager...test manager...stakeholders and clients.
wow i have collected few more information from deepak's blog....
Implicit Risk Context Approach:
A typical approach to test estimation is for a project manager or QA manager to implicitly use risk context, in combination with past personal experiences in the organization, to choose a level of resources to allocate to testing. In many organizations, the 'risk context' is assumed to be similar from one project to the next, so there is no explicit consideration of risk context. (Risk context might include factors such as the organization's typical software quality levels, the software's intended use, the experience level of developers and testers, etc.) This is essentially an intuitive guess based on experience.
Metrics-Based Approach:
A useful approach is to track past experience of an organization's various projects and the associated test effort that worked well for projects. Once there is a set of data covering characteristics for a reasonable number of projects, then this 'past experience' information can be used for future test project planning. (Determining and collecting useful project metrics over time can be an extremely difficult task.) For each particular new project, the 'expected' required test time can be adjusted based on whatever metrics or other information is available, such as function point count, number of external system interfaces, unit testing done by developers, risk levels of the project, etc. In the end, this is essentially judgment based on documented experience', and is not easy to do successfully.
Test Work Breakdown Approach:
Another common approach is to decompose the expected testing tasks into a collection of small tasks for which estimates can, at least in theory, be made with reasonable accuracy. This of course assumes that an accurate and predictable breakdown of testing tasks and their estimated effort is feasible. In many large projects, this is not the case. For example, if a large number of bugs are being found in a project, this will add to the time required for testing, retesting, bug analysis and reporting. It will also add to the time required for development, and if development schedules and efforts do not go as planned, this will further impact testing.
Iterative Approach:
In this approach for large test efforts, an initial rough testing estimate is made. Once testing begins, a more refined estimate is made after a small percentage (e.g., 1%) of the first estimate's work is done. At this point testers have obtained additional test project knowledge and a better understanding of issues, general software quality, and risk. Test plans and schedules can be refactored if necessary and a new estimate provided. Then a yet-more-refined estimate is made after a somewhat larger percentage (e.g., 2%) of the new work estimate is done. Repeat the cycle as necessary/appropriate.

Parametric Approach:- This approach assumes software development is kind of automatic and fully sequential process. Once efforts have been calculated developer will follow strict controlled process and will eventually deliver the product. Main methods used in this approach are a) LOC (Line of Code method like COCOMO) b) Function Point Analysis.
However what this approach fails to see is human factor i.e.
• People who are coding are not robots or machines
• Every developer is unique and has unique style of coding
• Motivation curve
• Learning curve
• Risks
• Technology challenges etc.

Top-Down Approach:- This approach considers that Goal of a project is at least visualized if not crystal clear. Hence based on the rough visual goal, timelines are exploded and drilled down to tangible and atomic goals. All goals are mainly achievable in few days to maximum in a week, hence while completing and integrating small goals, big goals can be achieved.
Best part of this Approach is it gives human touch to provide estimates of their own efforts. However it fails to see
• future uncertainties,
• risk,
• technology challenges etc
Bottom-up Approach:- In this approach, the goal is so vague that it is almost impossible to visualize final outcome. Hence while completing small initial goals, which are clear, main objective is achieved. This approach may include iterations and incremental development. Hence based on the number of iterations and incremental integration estimate can be given. Again the major limitations of this approach are same as Top-Down approach, however major benefit is, no two separate Goals of two separate projects are same and it may happen that the way Project has been conceived Goals look same however they are so different that not even same technology can be used
Analogy Approach:- This is most realistic approach in the sense that if we have delivered same product before we can estimate on the current project and provide a good estimate of it. The point to be noted here is no two projects are identical, at least the time dimension has to be different, in worst scenario, the whole team is new hence old learning curve and best practices may not be utilized.
It is the reality that successful test estimation is a challenge for most organizations, since few can accurately estimate software project development efforts, much less the testing effort of a project.
Powered by Blogger.