I’m saying goodbye to the term “Test Plan”.  To me, “Test Plan” implies a plan that details how the test team will measure the quality of the product is and report it back to the team.  While this an important piece of the a quality strategy, it’s not sufficient by itself.

I’m replacing the term “Test Plan” with “Quality Plan”.  This is a plan that explains how various people working on a feature will work together to ensure it’s delivered with high quality.

Quality isn’t just the responsibility of a single person, and as such, Quality Plans don’t have a single author.  Rather, multiple people will contribute to them at various points throughout the feature development cycle.  For practical purposes, I’ll have a tester being the "guardian” of the document, making sure it’s complete, up to date, that everyone is bought into the plan, etc.  Developers, program managers, and testers will work together on a unified testing strategy for the feature:

• The developer will describe how she’ll validate the code before she commits changes, which scenarios will be covered by pre-check-in tests, any testability considerations in the code, etc. 
• The tester will describe the additional testing he’ll do post-check-in and any other processes, procedures, test tools, etc. he’ll use to get the job done. 
• A program manager might contribute by ensuring the plan covers validation of end-user scenarios, making sure those scenarios are well documented, and tracking progress during feature development.

It may sound like a subtle difference in terminology, but I think it encourages a much bigger change in how a team thinks about designing in quality from Day 1 as opposed to the extreme opposite: “testing in quality” after the feature is “complete”.