At the point at which the source code has been released to QA, or after QA has successfully extracted a working build on which to perform QA, QA should take a snapshot of the Source code in the form of a labeled release.

This will enable development activity to continue uninterrupted and in parallel while QA efforts are under way in order to maximize development effort and the ability to utilize results. This also provides the ability to have checkpoints in the source codebase itself in the event that the enterprise may have to revert back to a previous release if failure is detected, post-deployment – Bad scenario, but definitely prevalent.

Imagine three modules A, B and C. On a specific date, say December 20, a specific version of A, B and C is handed over to QA, and they test it for three days. During these three days, developers continue to change A, B and C further, for future releases. At this point, on Christmas, if QA finds a small bug, and requests a re-build, it is mandatory to go back to the last known good state of the release instead of where it is now, so that the simple change can be made to get the current release working. It is also important that this simple change also be made to the current implementation, but not as important since that code has not been released yet.