We're talking about flow... Flow is something every project office manages at one time or another. Stuff moves through the pipe from requirements to deliverables. Sometimes, it needs a bit of help to move it along (We're from the project office and we're here to help!)
Fair enough, but how to help? .... Answer: do the math!
Look at this
Scenario: you've got to certify an object by testing it until you get 100 passes (of the test); or, you have 100 objects that need to pass a test. In this latter case, each object is similar (not identical necessarily) and thus the same test applies... thus, the same test parameters apply.
Expectations: From benchmarks or other calibrated input -- or from an educated guess that you will validate with actual observations -- you (your test manager) estimate -- because you can't know this for a certainty -- that:
- On the first attempt at the test, 40% of the tests will fail (Yikes!)
- On the second attempt at the test -- after some diagnosis and refactoring -- 20% of the original population will fail a second time, in this case 20 of the original 100. More work needed.
- On the third attempt at the test -- after more fix and repair -- all 100 objects have passed.
- On the first attempt at the test, 60 objects pass, 40 fail and require rework
- The second test is a test of the 40 reworked objects; 20 fail (by scenario estimate) and 20 pass. Now there are 80 passes total and 20 back in for a second rework
- On the third test, all remaining 20 pass (Amen!)
- Pipeline flow: 100 + 40 + 20 = 160 objects
- Test setup for a scope of 160 (resource commitment, test facility reservation, etc), NOT 100
- 160 units of testing. Effort or flow multiplier of 1.6 on this object-testing process. (call it a 60-20-20 process). Other ratios will yield different multipliers.
- 40 units of 1st order fix (1st order fixes may be easier than 2nd order fixes)
- 20 units of 2nd order fix (the harder stuff to fix)
