Triaged Tester

March 5, 2009

% of Dev effort for test estimation

Filed under: Estimation,Guidelines,Stratergies,Test Management — Triaged Tester @ 1:21 pm
Tags: ,

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.

Advertisements

March 3, 2009

Iterative approach for test estimation

Filed under: Estimation,Guidelines,Stratergies,Test Management — Triaged Tester @ 1:18 pm
Tags: ,

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 re-factored 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

March 2, 2009

Test work breakdown approach for test estimation

Filed under: Estimation,Guidelines,Metrics,Test Management — Triaged Tester @ 1:16 pm
Tags: ,

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

February 27, 2009

Metrics based approach for test estimation

Filed under: Estimation,Guidelines,Metrics,Test Management — Triaged Tester @ 1:15 pm
Tags: ,

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

February 26, 2009

Implicit Risk Context Approach for Test Estimation

Filed under: Estimation,Stratergies,Test Management — Triaged Tester @ 1:14 pm
Tags: ,

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.

Next Page »

Create a free website or blog at WordPress.com.