map.jpg 

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).

About these ads