Ever gone on a long car trip with kids? After some time they start growing restless and begin asking every 5 minutes (if your lucky) ARE WE THERE YET? ARE WE THERE YET? ARE WE THERE YET?!?!?!

I’ve had similar experiences in Development Projects. Close the release date we’d start getting calls from Product & Project Management asking us whether the product is ready to be released and if we can give them a date (even an approximation) for when will we be ready to go ahead. What usually happened in these situations was that Development proclaimed they were finished with all the features and now the QA was halting the project due to the bugs they were discovering in the product (like we were the ones who got them into the code in the first place…)

In my rookie days I used give the neutral answer that “we will be ready once we find and fix all the critical bugs”. Then after a couple of such projects I was able to find a way to give an answer that provided more information by giving visibility into the product via our test results and the statistics related to our bug detection and resolution convergence curves.

My experience is that bug detection behaves like a trend; if 2 weeks ago you detected 15 critical defects, a week ago 12 critical bugs, and this week 10 critical bugs, most probably you will detect between 6 and 8 critical bugs during next week’s testing. Bug detection trends can be represented by a curve that increases at the beginning of the project as you get more features and more people to start taking part of your testing operations, then it reaches a maximum peak when you get all your features and/or once you reach a critical mass of functionality to test, and then decreases as you start completing your testing scenarios and start running your regression tests.


If on top of this behaviour we also graph the fixing rate of the development we can then determine 2 things:
1. The time when development starts fixing more bugs than the testing team is finding per week. Even if this point by itself does not provide much vital information, it gives an indication that the project has reach the first turning point toward convergence.
2. By following this graph over a period of time we will be able to provide an intelligent forecast of the approximate time when we will be ready to release the product.


Even if the information on these graphs is not infallible, and even if we should always be prepared for the bug on the final CD before release, by using this data intelligently we are able to provide valuable information to the Organization regarding the time when the product will be ready to be released.

The main task of the QA team is not to be the Gate Keeper of the R&D, holding the product until it has been completely rid of bugs. Our Job is to give visibility into the process and product, and to provide information to all stakeholders that allows them to make their decisions concerning the product.

By making data our most valuable resource, we make information our most powerful tool!

Related posts:

  1. The art of transforming testing data into project information
  2. Do you have Information or Garbage in your Bug Management System
  3. What to think of when defining your Company’s Bug Lifecycle
  4. Severity vs. Priority of a Bug
  5. How to use easy to find bug information to improve the quality of your testing