QE ideally is a continuous process throughout the development process. The biggest complaint I hear from QE is that they often aren't sure what's completed ready to be tested or are told that areas are completed when they're not.

Depending on theproject scope and development environment I typically use a variation of one of the methods below:

"Phase releases" for larger projects: The team devided the code development phase into roughly thirds. Completion objectives for each phase is a list of features/enhancements that are completely ready to be tested in order to meet the milestone. Exceptions to the phase should be documented via Build Notes to prevent QE from testing areas that are still in development.

"Weekly builds": For smaller projects with a running list of features, an weekly build is done for release to QE. Included with the build are comprehensive "Build Notes" that identify the new features that have been added and are ready for testing. Combine this with aweekly report of bug fixes available in the build, QE has all the information to test new features as well as close resolved bugs.

The theme between both approaches is a clear communication and commitment on behalf of development of "what's ready" as well as some supporting documentation of "what's to be avoided".