Test plans?

I'm still not sure how I feel about test plans. As with all documents that help you think, the thinking part is great. I'm not sure how much value the plan as a document has once you are over the first thinking hurdle.

Of course, you should keep it a living document, but at what point does the maintenance cost exceed the remaining value of the plan? It's great to get you going, but at some point you know exactly what you need to do and the plan isn't necessary any longer. I've seen problems where this cutoff point wasn't respected and time was spent on the plan that would better have gone to testing.

I've had a lot of freedom in the test plans I've written. I've followed the IEEE template and I've made up numerous ones of my own. They all work if they get you to ask the right questions.

What exactly are we testing?
When do we expect the testing to happen?
What do we expect the testing to show us?
What are we going to consciously ignore because of project constraints?

Some of my development managers didn't care if I wrote a plan or not as long as the right testing got done. Others seemed to want the plan more than the testing. Biggest mistakes I've made are when I didn't realize what kind of manager I was dealing with in this regard. To some development managers, testing is a mystery and a plan removes some of that mystery. To others it is a false security blanket they'll later turn into a hammer and beat you with when you "missed" a bug that you should have "obviously" caught. No mention is made of the developers who coded the bug of course.

Maybe I know a little better what I think of test plans after this post. They are complicated and can get you into trouble if you aren't careful. If they ask the right questions they earn their keep, but don't let them eat into time better spent testing your software.