| Following are some approaches to consider: | | | | testing estimate is made. Once testing begins, a more |
| Implicit Risk Context Approach: | | | | refined estimate is made after a small percentage (eg, |
| A typical approach to test estimation is for a project | | | | 1%) of the first estimate's work is done. At this point |
| manager or QA manager to implicitly use risk context, | | | | testers have obtained additional test project |
| in combination with past personal experiences in the | | | | knowledge and a better understanding of issues, |
| organization, to choose a level of resources to allocate | | | | general software quality, and risk. Test plans and |
| to testing. In many organizations, the 'risk context' is | | | | schedules can be refactored if necessary and a new |
| assumed to be similar from one project to the next, so | | | | estimate provided. Then a yet-more-refined estimate is |
| there is no explicit consideration of risk context. (Risk | | | | made after a somewhat larger percentage (eg, 2%) |
| context might include factors such as the | | | | of the new work estimate is done. Repeat the cycle |
| organization's typical software quality levels, the | | | | as necessary/appropriate. |
| software's intended use, the experience level of | | | | Percentage-of-Development Approach: |
| developers and testers, etc.) This is essentially an | | | | Some organizations utilize a quick estimation method |
| intuitive guess based on experience. | | | | for testing based on the estimated programming effort. |
| Metrics-Based Approach: | | | | For example, if a project is estimated to require 1000 |
| A useful approach is to track past experience of an | | | | hours of programming effort, and the organization |
| organization's various projects and the associated test | | | | normally finds that a 40% ratio for testing is |
| effort that worked well for projects. Once there is a | | | | appropriate, then an estimate of 400 hours for testing |
| set of data covering characteristics for a reasonable | | | | would be used. This approach may or may not be |
| number of projects, then this 'past experience' | | | | useful depending on the project-to-project variations in |
| information can be used for future test project | | | | risk, personnel, types of applications, levels of |
| planning. (Determining and collecting useful project | | | | complexity, etc. |
| metrics over time can be an extremely difficult task.) | | | | Successful test estimation is a challenge for most |
| For each particular new project, the 'expected' | | | | organizations, since few can accurately estimate |
| required test time can be adjusted based on whatever | | | | software project development efforts, much less the |
| metrics or other information is available, such as | | | | testing effort of a project. It is also difficult to attempt |
| function point count, number of external system | | | | testing estimates without first having detailed |
| interfaces, unit testing done by developers, risk levels | | | | information about a project, including detailed |
| of the project, etc. In the end, this is essentially | | | | requirements, the organization's experience with similar |
| 'judgement based on documented experience', and is | | | | projects in the past, and an understanding of what |
| not easy to do successfully. | | | | should be included in a 'testing' estimation for a project |
| Test Work Breakdown Approach: | | | | (functional testing? unit testing? reviews? inspections? |
| Another common approach is to decompose the | | | | load testing? security testing?) |
| expected testing tasks into a collection of small tasks | | | | With agile software development approaches, test |
| for which estimates can, at least in theory, be made | | | | effort estimations may be unnecessary if pure |
| with reasonable accuracy. This of course assumes | | | | test-driven development is utilized. However, it is not |
| that an accurate and predictable breakdown of testing | | | | uncommon to have a mix of some automated |
| tasks and their estimated effort is feasible. In many | | | | positive-type unit tests, along with some type of |
| large projects, this is not the case. For example, if a | | | | separate manual or automated functional testing. In |
| large number of bugs are being found in a project, this | | | | general, agile-based projects by their nature will not be |
| will add to the time required for testing, retesting, bug | | | | heavily dependent on large one-shot testing efforts, |
| analysis and reporting. It will also add to the time | | | | since they emphasize the construction of releasable |
| required for development, and if development | | | | software in very short iteration cycles. These smaller |
| schedules and efforts do not go as planned, this will | | | | multiple test effort estimates may not be as difficult to |
| further impact testing. | | | | estimate and the impact of inaccurate estimates will |
| Iterative Approach: | | | | be less severe. |
| In this approach for large test efforts, an initial rough | | | | |