The Test Plan – Format vs. Content


The test plan is the framework for your testing activities. However, what is most important is the content not the actual format (whether its IEEE or an organisational format).

The test plan should outline what is being tested, how its being tested, what you do with artifacts generated during test and what happens if…. .If we become set on the ‘format’ then what we get is a process and document heavy testing activity that detracts from the actual testing!

How many times (i’ve seen many) have the TM or Lead spent hours, days, weeks on a plan, get feedback (which is usually minimal) and get it signed off only to have it resigned to the top drawer never to see the light of day!

If anything, the test plan should be a flexible document in the sense that the unexpected usually happens during testing. For example, what if one of your plan’s exit criteria says that testing is complete when 100% of the Test Scripts have been signed off but a blocking defect occurs that blocks 2% of those Scripts (and will not be fixed in this release). Does this mean the plan has failed? Were we wrong to make our Exit criteria so strict?Or does commonsense tell us that because the business have made the call to defer fixing the blocking defect to a future release then our test plan is still on track?


My point is that adherence to structure and format is secondary to the who, how, what, why and where’s. The structure gives a framework that we adapt to suit our situation (CONTEXT).

Author: bjosman

Principal Consultant at OsmanIT

10 thoughts on “The Test Plan – Format vs. Content”

  1. Hi Palani,

    Thanks for the comment. It would be easy to send you my ideas on what encompasses a test plan but that would defeat any possible learning occur here (from both sides) and would be void of your context. Please feel free to communicate further to give context on your test environment and the reason why you are after a test plan!

    Kind Regards

  2. Well the short answer is…it depends! It depends on your organisation, it depends on your project and it may also depend on own experiences.
    If you wish to follow a ‘standard’ approach then you could apply IEEE 829 (google IEEE 829 for details) – this sets out the Test Plan in a format that is probably used in some form or another, the world over – and in most cases it is used redundantly (i.e. it may contain ‘bloat’ and not much thought is put into the document, it gets signed off and then consigned to the filing cabinet never again to see the light of day.)
    Or one could use a test strategy ‘model’ such as James Bach’s Heuristic Strategy model (refer to for another article on James’ ideas on Test Strategy.
    I’ve mainly used the IEEE829 style though i would rather prefer something closer to a less is more approach. I think too often we don’t give enough information in our Test Plans – instead its something that we’ve recycled from previous documents without really questioning whats in them and what they say.

    I hope this helps!

    Kind Regards

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: