Stabilization Phase

I talked about importance of regression testing some time back where I pointed out why we should have one and how to drive it effectively. As I spend more time doing testing and going through releases, I am realizing that we need something bigger than regression (when not on happy path). The idea of regression is to uncover most of the bugs in the application and get it fixed based on Triage parameters.
Happy Path: Bug fixing rate is higher than the bug finding rate (in case of less buggy application). Sad Path: Bug fixing rate is constant and the bug finding rate is on a rise (in case of a buggy application). A project in either of the state can easily be identified by looking into the bug logging rate. Projects on happy path don’t need much attention and can easily be managed through regression phase. But for the project on sad path I would suggest to have a Stabilization phase instead of Regression phase. The notion behind Stabilization phase should be to be prepared for release to Production. Any bug tracking system used by a QA team accumulates a huge data, the onus is totally on us if we are actually mining it properly. For any project where we are done with the scope complete and entered the stabilization phase, we should start noticing the defect logging rate, defect fixing rate, defect density etc. Creating a Bug Convergence report actually helps in visualizing the same and gives a more realistic data in terms of when we should be thinking about the stable application, when we can start taking out potential release candidates for pilot users. Stabilization phase will actually make the team “Release Ready”.


Popular posts from this blog

The 3 qualities that will always help you become better at almost anything…

Test Case Paths : Happy, Sad & Bad

How to install Android Emulator on Windows