Triaged Tester

March 18, 2009

Stop Testing

Filed under: Black Box Testing,General,Test Management — Triaged Tester @ 9:14 am
Tags: , , ,

Time and again the most important question that haunts a tester – when are you stopping your test?

Well’ there is no right or wrong answer for this. But definetly you can concur at the time to stop testing using these items

1. All high priority bugs are fixed

2.The bug convergence shows good result

3. ZBB ( Zero Bug Bounce) has been achieved

4.The testing budget is achieved

5.The project duration is completed 🙂

6. The risk in the project is under acceptable limit

Practically item # 6 would be the main and most acceptable solution to stop testing.  Now what risks need to be monitored for these answers ? . I would go with – Test coverage, Number of test cycles & priority of open  bugs

March 17, 2009

Deliverables @ various phases

Filed under: Black Box Testing,Deliverables,Test Management — Triaged Tester @ 9:10 am
Tags: , ,

This diagram does not depict when and where are the test plan and test strategy documents generated.Ideally, these documents are ready before you begin the test activities

test Deliverables @ phases

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.

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

Next Page »

Create a free website or blog at