Sunday, February 28, 2010

Standard Disclaimer - And an Apology...

Ever since that I started this blog a couple months back, I have been asked by a lot of peers and ex co-workers if I'd categorize them as members of the group of "Fake Software Testers".

My answer to all --- Yes and No.

To clarify, this blog does not have any direct reference to my current and past co-workers, nor do I even try to implicate that they are fake testers. To be honest, I have had the privilege of working with a lot of the brightest minds in the past couple of decades. And though some of my current colleagues do not realize it, their approach to the field of software testing makes me pale in comparision!!!

But, having said that, I have been seeing a lot of fake testing in the past few years happen, which is what I am trying to set right with my blog. It saddens the heart to see a lot of these fake testers, being hailed as very good testers. I don't have a problem with them being rewarded... but, when they are given bigger responsibilities, we are setting them up for failure.... I am not too worried about the projects failing, but.... if these testers are pushed into testing software which saves lives, or flight software, then that is very dangerous.... Their failure to detect a defect might kill a few lives!!! --- that's what I am worried about.

Even I --- for a considerable amount of time, have been (and sometimes, continue being) a fake software tester ----- and I realized I'd remain so until someone pointed it out!!!

That is why, I am trying to create a blog which would also talk about some of the fake/wrong practices of testing, which is so much prevelant these days. I am also trying to share a few of my experiences with this.....Not all of it is right, and not all of it is wrong. It's only when I try to don the hate of a fake tester that I am able to see what is right and what's wrong... from purely my perspective!!!

And 1 more thing... I have not declared my identity on this blog. That's for only 1 reason ----- it gives me immense satisfaction, to being referred to as "The Fake Software Tester"!!!!!

Saturday, February 27, 2010

English - "A thinking language"...!!!

Was just reading Pradeep's blog on "Coaching testers on Bug Reports, Advocacy and Credibility" @, when the following thought took shape in my head.

In all our interviews, we ask for a list of known languages of the candidates. But, we never ask for the "Primary Thinking Language" of the applicant, neither do we make an effort to find out what that is.

Going through some of the awful bug reports that Pradeep has reported, and having sampled much more of the same in my life, I am of the opinion that we need to look at ways to identify the tester's "Primary Thinking Language", and all our training programs on communication skills should also look at how English becomes our primary thinking language - since English is the universally accepted language for defect reporting.

We ask them for languages that they speak, they write and they can read. But have we ever, for a moment, thought of the importance of identifying the "Primary Thinking Language" at all? Having posed this question, what do I mean when I say "Primary Thinking Language"???

The way I'd define it is... Your Primary Thinking Language is the language of the word that comes immediately to mind when you think/look at an object or think of an emotion. We did the following experiment with a group of people who were predominantly tamil speaking and another group who are management grads from IIM.

We showed them a door, An Angry Amitabh Bachan scene from a movie, a key to the door, a picture of a child sleeping and the photo of a tomato.... and asked them to answer whatever comes to mind in the 1st second.... The answers that they gave...

Majoring of answers from the tamil speaking group --- Kadavu/maram, padam/cinema/kovam, saavi/pootu, kuzhandhai/azhagu/thookam, thakkali... (Words that first came to their mind were in their mother tongue... Conclusion ---> the primary thinking language --- Tamil)

The English speaking Management Graduates rattled off the following words --- Door, anger/flick/movie, key, child/sleeping/bliss, veggie/sandwich/rotten tomato..... That helped us conclude what's their "Primary Thinking Language" was --- English, Obviously.

You can do this experiment with someone you know to identify your primary thinking language and you would know what I am trying to say here...

Training Deparments --- Please take note.... Please help employees identify their "Primary Thinking Language" and work with them long-term to make English as the "Primary Thinking Language", so that it would be beneficial for both the employee and the company in the long run....

And I don't think that this is a problem specific to India... I am sure this problem exists in many countries where English is not the primary speaking language.....

And yes.. this article has nothing to do with fake testing... Just some thoughts that came to mind on reading Pradeep's blog... The fake tester's off on a long weekend... See you in March!!!

Thursday, February 18, 2010

The 1st 10 mins...

What is the most important time of the day? For me, it's always the first 10 mins of today and the last 10 mins of the previous working day. Most often than not, these 10 mins have always decided on the future course of actions for the entire day. They have determined if the entire day is going to have a smooth flow, or if there are going to be rough patches.

As soon as you enter work, your investment on the first 10 mins would reap the results for the rest of the day. Please put all stops in place and finalize your day's plan during the 1st 10 mins. Please tell your boss that you can't be disturbed during this time. Please inform your sub-ordinates that you cannot be disturbed during this time. Having put all these stops in place, what do you do in the 1st 10 mins?

Well, I don't know what you do (how can I :), but here's what I do during these 10 mins.

1) A lot changes during the previous day....
Most probably, most of our project team members live across the world in a different timezone. Please check your emails and make a quick check of items that you need to accomplish during the day.

2) Plan for the top 3 things that you want to do for the day.
On Paper, draw a simple list of top 3 things that you need to complete for the day. It can be completing a review, completing some documentation, doing some testing, doing some test data preparation, or whatever... But, please have a good clarity on the top 3 tasks that you plan to achieve for that particular day at work.

3) Planning for interruptions...
All of us get interrupts.... how do we handle interrupts? We don't have to look far... we only need to take a good look into the mind of a very effective operating system to understand how the system handles interrupts and if you study it, you would know that the system handles interrupts in the best possible manner. You need to mimic the same... it's too simple, really!!! The moment you get an interrupt, all you need to do is to see if you have to place that task among the top 3 activities for the day. If not, it can wait!!!

4) Plan for what to discuss during the meetings on this day...
Make a quick list of meetings that you need to participate... And plan for the top 2 things that you want to talk about in those meetings. Nobody likes someone who keeps talking and talking... By talking less, you would be able to create the focus on the most wanted items. Make a list of the things that you want to talk in meetings for the day.

5) If you feel the need to decline or postpone meetings, do it at this time.
You cannot be in all the places at all the time. If you feel that you need not attend meetings, please decline them 1st thing in the day. There is no harm in declining meetings. You have to do prioritizations effectively.

6) Finalize the effective working time during the day. The time when you will not be disturbed by anyone...
This is something that I do religiously... For at least 4 hours during the day, please ensure that there is no disturbance. Do not take coffee breaks.. do not answer phones... do not take gossip breaks... email breaks... browsing breaks.... break from breaks, etc.etc.etc... For 2 hours in the AM and 2 hours in the PM, please focus only on deliverables. I call this EFFECTIVE WORK HOURS. Makes a world of difference to your deliverables...

7) Playing hooky from work is always important.... -
Finalize the time of the day when you play hooky and read fun-emails and internet browsing, Office Gossips, Purchasing stocks on the stock market, etc. None of us refrain from this and in a way, this is always important.

And very important... though it is very important for you to be at the beck and call of your boss, please don't do that in the first 10 mins of your day...

Please keep your boss, your boss's boss and your boss's boss's boss far far away during this time :) !!!

The fake tester always reaches for a cup of coffee and checks all fun forwarded emails before starting off. His entire day gets screwed up, and he cannot prioritize. He spends most of his working time in something which is not important at all. For example, If you have 90% notion that a feature will not be delivered, why would you need to spend time on testing it? Please remember... investing in the 1st 10 mins of the day would be very effective for the entire day, and you would reap results for the rest of your long career!!!

What the fake tester does not realize is that...... Dedicated planning during the first 10 mins of the day, would ensure that you own the entire day!!!!!

Tuesday, February 9, 2010

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"!!!!!