Building a test plan from Woe to Go using Heuristics, Mind Maps, and Test Charters

Creating a test plan can be a daunting task, especially when under time pressure.  "We need you to test this application and, oh, we go live next Monday."  How do you create a plan to test that is accountable, transparent, and structured, yet lightweight enough that can quickly be understood by developers, project managers, other stakeholders, and new testers that may be brought on to help out?  And not only that, but be created quickly?

We should be aiming to automate all our testing

You've heard it.  I've heard it.  This is my response:

Don't (explicitly) charge your clients for testing

Software development houses who write bespoke software will usually provide a quote to develop or customise an application.  Often, it's broken down into "Project management, requirements gathering, development, testing/QA, etc etc".  In my experience, it is a mistake to break testing off as a separate quote to give to clients.

Why?

Before we begin

"Many arguments appear to be about conclusions, when they're almost always about premises."

Before I begin, I think it's important to lay out exactly what I mean when I use certain words and phrases. Then if you disagree with me, you can decide if we're arguing about conclusions or premises. :)