the fix for final testing and fixing of the stabilized version (at least two weeks for small systems and at least one month for large complex ones).
Stabilize and control the test environment. An argument can be made that more stop-and-go interruptions of test execution are caused by gremlins in the test environment than by any other cause. Ideally, the test environment should be established and tested comfortably before it is needed. The test environment should include tools to manage the test configuration, diagnose problems in the environment, and easily reconfigure the environment from test to test.
4. Get off to a Quick Start
Start the test planning early. As was mentioned earlier (it is worth repeating), allow plenty of time up front in the project for the testers to climb the learning curve, develop test cases, conduct peer reviews of test cases, learn automated test tools, etc.
Ensure the right people are involved from the very beginning. To ensure the right functional specs are written at the beginning of the project, it is important to have the right talents and viewpoints on the project team. Otherwise, much time is lost when the project has to be reengineered.
While team formation is the responsibility of the project leader, an appropriate role for QA is to verify that the correct mix of marketers, customer representatives, hardware engineers, documentation, and customer support repsare involved.
Be proactive. Many test and QA groups operate reactively: they are so busy with the test du jour that they have no spare time and energy to become proactively involved in future projects during those projects' formative stages.
In other words, if you are currently involved for twelve hours a day testing System A, you have no time to get involved early in System B, which currently is being defined and which will be your next testing assignment after System A. It takes foresight and adequate resources to cover both the test execution for System A and the test planning for System B simultaneously.
Be organized and well prepared for the test . Involve the testers early in reviewing the system requirements for testability. Set up and check out the test facilities and test case automation early, in parallel with the system development activities.
Remember the "push-pull" effect. Any efforts to prepare and build test infrastructure must happen in the first third of the test duration; after that, it is too late in the scramble to finish the project. Test automation especially needs a long lead time, and is not feasible on test projects that are done at the last moment.
5. Streamline the Testing Process
Automate more of the test cases. A test group at ADP, the large information services firm, reports that they reduced the elapsed time for a group of their testing projects by 60 percent through automation.
There is a danger here, however-most test automation efforts are not effective, which imperils the timely delivery.
Use risk prioritization to focus the testing on the most critical areas of the system. Use the concepts of risk-based testing to prioritize the test cases and determine how much test coverage is sufficient. According to research at Bellcore, the top 5 percent of the test cases uncover almost 50 percent of the defects, and the top 15 percent of the test cases uncover 75 percent of the defects.
Reuse test plans, templates, and test cases. The idea is to avoid reinventing the wheel, to reuse known and field-tested test cases, and to provide consistency across tests. In most cases, automation is a prerequisite for reuse of test cases.