Test Cycles

NVP considers a Test Cycle to be one complete execution of a group of test cases. The reason we’re interested in this particular item is that it leads to estimation. The first questions in any testing project are:

1. How long is it going to take?
2. How much is it going to cost?
3. When will you be done?

These questions can be difficult to answer when starting a project as a new tester or test manager or with limited experience in the software one has been asked to test. Having test cycles helps solve that issue.

In order to answer those questions we need to:

1. Define the contents of the group of tests constituting the cycle
2. Get an estimate of how long each test will take
3. Add up the resultant times
4. Build in some contingency
5. Use that as an estimate for the length of the cycle

The above gives us an estimate for the length of a single cycle.

The next question is how many cycles will be run. Our answer is usually three at a minimum on the grounds that there are two debug cycles and hopefully a clean run. In our experience we have managed to get away with two cycles but that’s unusual. Many times it’s many more than three especially if the code is weak or the full requirements are still being worked out. Usually you will have an idea after your first test cycle as to how many will have to be run.

In order to answer the question of when you will be done, you then need to multiply the number of projected cycles by their individual lengths, add in time for the fixes to be made and promoted and use that as an estimate of the completion date (and the cost by using the chargeback rate).

1. Do you have defined test cycles?
2. What is the worst case for number of times they had to be run?
3. What is your least number of runs

Next Week: Process Improvement