Currently I am doing a large V-model waterfall project with a three month testing period and 500+ requirements. To track the progress I want to dust off my old “test progress tracking” method that I matured and described in 2011 and 2014.
The approach was documented in two articles for “The Testing Planet” a paper magazine by the Software Testing Club. The “STC” later became the now world famous Ministry of Testing. Unfortunately the original articles are no longer available on the MoT site – they are on the WayBackMachine. So not to track down that path, here’s a recap of:
- A Little Track History that goes a Long Way [The Testing Planet by Ministry of Testing, July 2011] The purpose of this tracking tool is to collect just enough data to answer the frequent question “Will we finish on time” [https://web.archive.org/web/20160410200818/https://www.ministryoftesting.com/2011/07/a-little-track-history-that-goes-a-long-way/]
- The Daily Defect Count and the Image of a Camel [The Testing Planet by The Ministry of Testing, April 2014] Count the defects daily – the ones that are part of the project work load. The number goes up and down during the cycle – why and what can you learn? [https://web.archive.org/web/20140718052546/https://www.ministryoftesting.com/2014/04/daily-defect-count-image-camel/]
A Little Track History that goes a Long Way
For large (enterprise, waterfall) projects tracking test progress is important, as it helps us understand if we will finish a given test scope on time. Tracking many of projects have given me one key performance indicator: daily Percent Passed tests as compared to an s-curve. The data in the S-curve is based on the following data points, based on numerous projects:
| Time progress | Expected Passed Progress |
| 10% | 0% |
| 20% | 5% |
| 30% | 10% |
| 40% | 30% |
| 50% | 45% |
| 60% | 60% |
| 70% | 75% |
| 80% | 90% |
| 90% | 95% |
| 100% | 100% |
If the “Actual” curve is flat over more days or is below the blue trend line, then investigate what is blocking the test progress… defects perhaps:
The Defect Count and Camel Image
During a large project like this the active bug count goes up and down. No one can tell what we find tomorrow or how many we will find. In my experience tracking the daily count of active defects (i.e. not resolved) is key, and will oscillate like the humps on a camel:
If the curve doesn’t bend down after a few days there are bottlenecks in the timely resolution of defects found. When the count goes up – testing a new (buggy) area is usually happening. Over time the tops of the humps should be lower and lower and by the end of the project, steep down to 0.
And thus a little track history has come a long way.
Complexity is a Matter of Perspective 