There are two approaches depending upon the maturity of the organization.
1. For low maturity organization, it is heuristic approach which may be considered as 'Expert's Opinion', 'Team Judgment' etc
2. For high maturity organization like CMMi Level 4 and above, it must know how many test cases to be written for the given application, how many iterations of testing will be required, how many defects are expected, what is the productivity in writing test scenario, test cases, defining test data, performing test cases, logging defects etc.
This is based upon historical data.
Solved problem from my book (If anybody wishes to buy this book, it is available at Tata McGraw Hill Publication stores or I can be contacted)
An application is to be tested and information available with organizational database is as follows. Estimate the efforts required for testing.
Efforts required for test planning – 5 person days
Percentage of activities related to testing such as meetings, reporting etc – 15%
Test case writing efficiency – 50 test cases / person day
Test case execution efficiency – 100 test cases / person day
Test scenario writing efficiency – 10 scenarios / person day
Time required to enter 1 defect – 15 minutes
Time required for reviews – 10%
For the given size of software,
No of test scenarios – 500
No of test cases – 7000
No of iterations of testing – 3
Expected number of defects – 800
Estimation would be
Time required for writing test scenarios = 500 / 10
= 50 person days
Time required for writing test cases = 7000 / 50
= 140 person days
Time required for reviews = 10% of (140 + 50)
= 19 person days
Time required for 1 iteration of testing = 7000 / 100
= 70 person days
Time required for 3 iterations = 70 x 3
= 210 person days
Time required for entering defects = 800 x 15 / (60 x 8)
= 25 person days
Total time for execution = 50 + 140 + 19 + 210 + 25
= 444 person days
Time for other activities = 15% of 444
= 66.6 person days (67 person days)
Time required for test planning = 5 person days
Total time required for testing = 444 + 67 + 5
= 516 person days
There is no simple answer for this. The 'best approach' is highly dependent on the particular organization and project and the experience of the personnel involved.
For example, given two software projects of similar complexity and size, the appropriate test effort for one project might be very large if it was for life-critical medical equipment software, but might be much smaller for the other project if it was for a low-cost computer game. A test estimation approach that only considered size and complexity might be appropriate for one project but not for the other.
Following are some approaches to consider:
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 (eg, 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 (eg, 2%) of the new work estimate is done. Repeat the cycle as necessary/appropriate.
Percentage-of-Development Approach: Some organizations utilize a quick estimation method for testing based on the estimated programming effort. For example, if a project is estimated to require 1000 hours of programming effort, and the organization normally finds that a 40% ratio for testing is appropriate, then an estimate of 400 hours for testing would be used. This approach may or may not be useful depending on the project-to-project variations in risk, personnel, types of applications, levels of complexity, etc.
It depends on the complexity of the project where one has to define:
- No. of resouces available.
- Resoure exeperience.
- Dead line of the project.
- And all other risks on the project will decide the Test Extimation.
Test effort is measured by matrices:
1. Product: To check how many KLOC(Kilo lines of code) has been written.
2. Quantity: To Check how the Person Month(PM) i.e. how much one person work for 1 week.
3. Productivity: (Bugs found by tester)/(Bugs found by tester + bugs found by user)