especially if this test cycle has to be repeated many times before the testing is done.
With overlapping testing and fixing, the turnaround time can be reduced. The danger is that a test that was just executed may no longer run the same way after the fix is introduced into the system. The fact that a test case worked correctly before the change in no way guarantees that it will still pass after the change.
In apparently unrelated (e.g., structurally decoupled), low-risk areas of the system, where the chance of error propagation caused by a change is low, this overlapping of testing and fixing can be acceptable.
Partly overlap the phases of testing. Traditional testing proceeds in linear sequence of phases from unit to integration to system to acceptance testing. Unless the system is already unusually clean prior to testing (in which case these phases can be hurried through), it is not a good idea to skip phases. The purpose of the unit test, for example, is to ensure that each component is as clean as feasible prior to the more complex multi-component integration and system testing.
These phases can be overlapped to expedite the overall test process. With careful coordination, the build and integration test could begin before the unit test is 75 percent complete. The system test could begin when the integration test is only 75 percent complete.
For example, partial builds and integration testing can proceed in parallel with the completion of the unit testing. System testing can begin without all components being ready and present in the system version under test. Acceptance testing could proceed in parallel with the system test, provided the client understands the system may appear more buggy than normal.
Move to a daily (or at least a more frequent) build cycle. Frequent build cycles use incremental regression testing with a steadily increasing set of automated regression test cases, and can encourage an earlier start to integration testing.
Improve the coordination among the groups involved in the test, debug, and fix cycles. Often unnecessary delays occur because of bureaucracy, lack of coordination, and misunderstanding. The overall project manager and the test manager should be on top of this, but often they are distracted by other issues.
Empower the test & QA people by building a mutual respect between these people and the ones who are building and maintaining the system. Not listening to the advice of the testers often causes delays.
Limit the fixes to be made prior to system release. Restrict fixes to the unambiguous showstoppers (severe problems), to reduce the rework and retesting. Establish a process to review and approve the fixes that must be made before the system is released, and minimize the number of retest cycles before delivery.
Tighten version control and change control. Lack of adequate control over changes and of system and component versions can lay waste to any schedule. This control needs to be applied in development, in testing, and in the field. It applies to platforms, configurations, and documentation as well as to the software itself.
Either a software configuration manager (SCM) independent of both developers and testers should perform this role, or if there is not a separate SCM, then the QA group should undertake the responsibility. To assume that the developers will simply coordinate versions among themselves is a fatal mistake.
Write problem reports that facilitate debugging and fixing, and don't impede it. A problem report is the mechanism that initiates the follow-up debugging and fixing actions. An effective problem report is clear, accurate, and useful to the person who will be doing