The Forever-Incomplete Test Plan.....

Ha Ha... Is this the billionth blog on a test plan?(Can a billionth blog exist.... food for thought :))!! Ever wondered what most of these nerds above the managerial hierarchy do on an almost every day basis? If the tester slogs the whole day, what does the test manager contribute to the project at all? Let's face facts!!! All Managers are over-heads!!! But, are they??? In a way, Ain't them all infamous for planning :) ?

Well... like it or not, most of their daylight hours... and moonlight hours... goes into planning... and for the test manager, the test plan should be a holy-book of sorts for the entire project, or program!!!

What does the test plan mean to the stakeholders, project management group and testers? Why do you need a test plan and what does it try to achieve?

Ask the fake tester, who, without a blink, would reply stating that the test plan is created for the sake of the Quality team who does regular audits. I don't blame him. That's his true belief!!!

And what would the true practitioner say? He would not give an answer in the first place!!! Test Plans mean different things to different people and the true manager would understand it. For the Stakeholder, it would mean about knowing release cycles, turn-around time.... for the project management group, it would list out the hardware/software requirements, etc.... for the tester, it'd say who'd be testing what module, etc.... for the customer, it'd talk about acceptance criteria, etc. etc. etc.

My top 4 myths about the test plan... - And what a fake tester would call - "4 Top requirements for a test plan :)"

1) It is always an MPP/word-document
I have seen this so many times in my life. A test plan is always seen to be a MPP or a test document. Why? A plan written for a 100 year project written very simply on a single sheet of paper, would also constitute a test plan. Why can't a test plan take the form of a simple PPT addressing whatever it needs to address? What a fake tester does not realize is this - Planning is all in the mind!!!

2) After customer sign-off, please do not update the document at all.
A very common occurance. The customer is always very eager to see the test plan... and the project management usually blackmails him to sign-off the test plan. Now, the test manager, having seen the customer sign-off, checks in the test plan document into the VSS/project repository archives. He tries to dig it out only during the audits... Completely WRONG!!! Please understand that the test plan is a living document and needs to be constantly updated... Else, it
will not server the purpose in the first place. Please update whatever needs to be updated into the test plan on a very regular basis.

3) Look out for the company template and fill in your test plan as per that template...
Whenever someone asks the test manager for a test plan, he does a deep-dive into the company document archives, digs out any document that has a test plan in the name, removes content from all sections, fills content in all the sections and submits it to you for review. It's not uncommon for you to see a L&P sections in a test plan for a 3-4 page website, which would eventually get decommissioned in the next month. The true practitioner, would use his common
sense to include only relevant information in the plan, which would be very short, but.. very important... serve the purpose!!!

4) It has to be a 100 pager document :)
And the mother of all myths... A test plan has to be a 100 pager. So many times, you review test plans to find it filled with useless information... Information soon going to be extinct, or information that you already know... If it's known information, why do we need to put it into a test plan? Sample this... A windows application, having just 3 screens... used to check a job interface.... ( a job that runs once a quarter, yea.. the same job that's gonna be decommissioned in the next 2 quarters)... has a 243 page test plan. A 243 test plan for a 3 screen application? Sometimes, in our eagerness in pursuit of perfection, we tend to overdo things.. and this is an example... Visualize this!!! The project would have an estimate of 20 days, but the estimation to
create the test plan would be 40 days!!!

Having said all that, from my personal experience, what I feel are some of the top 6 things to keep in mind while creating the test plan:-

1) Why do you need the test plan? Duration of the project? Internal/External?
Quick questions... Why do you need the test plan at all? Is it to satisfy the client or to satisfy project management requirements? How long is the project going to go on? Is this an internal or an external customer facing application? Please answer these questions before starting off on the test plan. Answering these questions would provide you the mostly correct direction that you need to take off in... Mostly, internal applications planned for 1 months seldom require a test plan.

2) Highlight all risks , issues , Assumptions and Constraints-
Having decided to create a test plan for your project, please list all risks, issues, assumptions and constraints in separate sections with appropriate contingency and mitigation plans. What is very important over here? That you, as the writer of the test plan, understand the differences between a risk, issue, assumption and constraint. You would also need to be able to recommend suitable contingency and mitigation plan. These are project management terminologies. The fake tester would easily be able to call out the risks, but it's only the TTP (True Testing Practitioner) who would be able to give a lot of thought to this section and sometimes, ask for help from other people to fill out this section. Sometime in the future, I'll write a separate topic on this.
Even when reviewing a test plan, it's very easy to look at this section and this would clearly differentiate between the true and fake testers!!!

3) Automation plans...
Automation test plan. This is something for which, as part of test plan, you would also need to know the development plans. Not only dates, but how development is planned and delivered to test so that the atuomation plans can cover this. Also use this section to explain to the readers, if automation would be an overkill. Also talk about criteria to choose the best automation tool, so that it provides cost requirements also to the project amnagement teams. It also gives them sufficient time to procure licenses, or re-use existing unused licenses.

4) Plans for testing Non-functional requirements...
Sadly speaking, half of the world start thinking of the non-functional requirements when they start to fill in this section in the test plan. The other half? They dont even think about it while filling this section. It is very difficult to find testers in this world, who understand the concept of testing for non-functional requirements, and who are able to foresee the potential business impact if these are not met. Trust me, plans for NFRs cannot be created overnight. A lot of thought needs to go into filling, or rather, thinking about this and how you would proceed to testing these items.

5) Plans for test data, masked like-live data...
Never try reinventing the wheel. why? For the simple reason that it's already been invented!!! ... Likewise, if you have an input stream coming into the live servers, try to have the same feed coming into the test systems so that you can test with like-live data. Do not compromise on test data, since they would be the driving parameters to predict behavior in production after go-live!!! If data received in the test systems is masked, please work with your bosses to
ensure availability of unmasked data. Always remember - The more you have to unmasked like-live data, the more defects you'd unmask!!!

6) And most definitely, to state what is out of scope...
My personal favorite section, that I have saved for the last!!! As much as what you are going to be testing is important, equally important is the areas that you are not planning on testing. Business, Stakeholders need to understand this scenario before approving your test plan, so that they would know what is not tested.

Having listed the above, here's what you need to keep in mind while you write the test plan- if you are still awake, or haven't browsed to another site by now ----- A Test Plan, however hard you try, is never ever a single day effort. All those, who disagree with me, is either a "Pure" Genius, or "just Another Fake Tester"!!!!!

Adios.....