When testing activities becomes complex or need a trend spotter – that’s where I shine. I’ve seen things you people wouldn’t believe. Browser wars off the shoulders of the millennium, mainframes glitter black-green and management shooting for delivery gates. All those moments are not lost in time, but curated and internalized. Sometimes as more of a hunch or a smell – other times on data collection after data collection. Seriously I have excel files of tracking testing activities at least since 2010. …!
Every time I have a non-trivial amount of test cases or a non-trivial amount of time I pull out my trusted sword – the s-curve progress bar. The key lesson is that no actual progress is linear. If you have A number of tests to complete in X number of days, the expected progress pr day could never approximately be A divided by X. Not even as an approximation. The underlying linear approximation is a bias. The truth is out there, and it’s polynomial.
- The inexperienced test lead would just plow along with no plan.
- The skilled test lead would calculate, triangulate and split every atom
- The experienced test lead would make an intentionally loose plan.
The s-curve not a tool for what ever tests you would usually fit in your average sprint, it’s for the long haul. A minimum would probably be ten tests and ten days. The original data points where gathered under six to eight week long testing activities three times a year for four or six years. 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 Way Back Machine.
- 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 you plot these data points in excel, you can add a 3rd order polynomial trend-curve to render the graph for you.
A recent example
In early 2026 I was leading a major testing effort, and I started tracking the test progress according to the s-curve. This is the actual graph of tracking the three sub-activities:
The top line is fine, plotting away with better progress some days than others. The grey line shows a clear blocker at both red markers. Similarly challenges with the yellow lines. Your usual test tooling would just tell you a percentage completed per day, but you would never know what impact it has if it stays the similar over a range of days. The observant reader will notice the drop in completion percentage, that’s when the number of test cases have increased. Which can be sound and required – but does impact the progress and hence finalization time.The s-curve adds an projection that you can relate the date point to. And get a direction for management decisions.
The Defect Count and Camel
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.
Keeping track is the key lesson here – the s-curve helps you answer with the confidence of all my data points when things are business as usual or when it’s time to step up.
[The primary parts of this post was originally published on jlottosen.wordpress.com in October 2019]