Effective and timely planning can have a huge impact on your testing success. To proven test planning methods and techniques, including the master test plan and specific test plans for acceptance, systems, integration, and unit testing. How to manage test activities, estimate test effort, analyze risks, achieve buy-in. test measurement and reporting tactics for monitoring and control.

Who should be writing the testing plans and when this should start. Should these plans be written by the developer or the publisher? Should a draft be written at the first playable build, or even eariler? Again, there is no one 'correct' answer; just factors that may help you decide what is right for your environment.

Having the developer write the test plan can help keep the integrity of the original product and can help ensure that a more thorough test plan is written. Having the publisher write the test plan can help free up developers to work in their respective disciplines. Writing the test plan early in the development stage can also help the developer discover any problems before they appear, while waiting until later in the development cycle can make for a more thorough test plan.

Having the development team write the test plan can overwhelm the developer and prolong the development time. Having the pulisher write the test plan may completely miss the mark on what to test for. Writing the test plan early in the development stage can lead to makeing too vague a test plan, while waiting until later in the developer cycle can make for a test plan that is overly complex.

It's not a bad idea to have the developer start a preliminary draft of a test plan and then pass it off to the pulisher to write the final stages of the test plan. Also, handing over the design document can help the publisher write a more thorough test plan. Ideally a test plan should be a living document. The test plan should be started as early as possible and be continually updated and revised as the development cycle moves forward.