Fake Software Tester’s Guide to attend meetings…

The title to this post tells what this post is all about. A common scenario as you grow up the perceived corporate ladder would be a need to attend a lot of meetings. Once you grow above the managerial level, plan to attend at least 4 hrs a day in non-productive meetings. And some of these meetings, you would have to attend even though you have no idea on what it is all about. And this post is about surviving such meetings.

Listed below are a few survival tips for such meetings – wherein you don’t have an idea on the topic being discussed.

1) The sandwich Blackberry method
A large sandwich and a blackberry can be your saviors. Walk into the meeting with a large sandwich and constantly, keep fiddling on your blackberry for the entire duration of the meeting. Walk out of the room every 10 minutes to attend to that very important phone call and keep walking back inside. You can be rest assured you won't be troubled by anyone for the duration of the meeting.

2) The copy-Paste method
Before the meeting, grab your team member who's attending it and ask him on what he's going to talk about. Ask him a few questions and ensure that you remember all his answers. Send him off on any errand to ensure that he doesn't attend the meeting. Now, re-state whatever he's told you and answer the same questions that you've asked him. Nobody would disturb you after you've made your point.

3) The Magic words
Remember these words - Bottom Line, Bird's eye view, Revisit, Thinking Hat, out of the box, Paradigm, Game Plan, win-win, Leverage, etc.
The trick is to pick 2 words from above and form a sentence, at any time during the meeting. Some examples I have are below:-

a) Guys, it's time to put on the thinking hats to think of a win-win proposal
b) Folks, let's come up with an out-of-the-box solution, which is pro-active and leverages our strengths.
c) The Bottom Line is that we need to revisit if we are doing things the right way. Take a step back to have a Bird's eye view of the solution.

You can try this exercise yourself and within a few practice tries, you'd become a master at it. You can create such statements from these words randomly and you'd sound like a veteran of senior management.

4) The Blame-it-on-others Method
Start off a conversation at the beginning of the meeting to talk about bad food in the canteen, rising fuel bills, lack of facilities in the company, bad candidates lined up by HR for interview, unrealistic client demands, etc...

5) Google will help you
If it's a meeting about a product evaluation, do a vigorous Google search 1 hr before the meeting. Scribble notes from all over the internet and present them as your viewpoint. Mostly, nobody would know and you can escape unscathed.

And my pick goes to the method described below... the best thing to do is....
6) Being honest
Yes. The last way is honesty. Stand up and tell everyone that you will be unable to provide any justice by your attendance, since you have no idea on what's being discussed. Tell everyone that you think you'd be better off doing something productive, than be a part of it and walk out. That's not something that happens very often, but I guess it's the most honest way.

If you can think of more such practices, I'd be happy to hear them and it would be great if you can post them in the comments section!!!

Well, what about those telephonic meetings that you need to dial in to attend??? Well, save that thought.... more on those another day!!!

The Defect I Leaked

Earlier in life, in the late 90’s, I was hired to test a software application's installation. After the usual late hours, Development fights, etc., I certified that the product works fine and Okayed the release.

What Happened then?
Within 1 day of going live, the support team was flooded with a zillion calls saying that the application does not get installed. All the installations aborted with the error message - "INVALID OS". The products had to be re-called, the defect fixed and re-shipped.

Root Cause on Investigation
The installation software had logic to determine the version of the Client machine's OS. Both Dev & Test assumed the location of this entry in a particular location, while most of the live systems had this info stored in a different location in the registry. As a member of the test team, I did not do sufficient research before testing and missed out this important detail, which at that time seemed insignificant to me.

Who's to be blamed for the Fiasco?
3 People who were responsible --- I, Me & Myself.

Defect Leakage --- A 1st for me
It was the 1st defect I leaked which had very high business impact. The fault was mine, mine & mine. Like so many other people in the project, I assumed that the operating system version is stored at a particular location only. I assumed that it cannot be stored elsewhere and so, I DID NOT TEST FOR IT. BY ASSUMING, I LEAKED A DEFECT!!!

Till today, the bug haunts me every time I take up a testing assignment. It is the fact that I can still leak a defect makes me more determined to ensure that I don't leak defects at least now.

A Fake Software tester...
--- Never admits his fault to a defect that he's leaked
--- Always thinks someone else is to blame for a defect that he's leaked
--- forgets the leaked defect too soon in life and invariably, leaks many more
--- Tries to pass the root cause for defect leakage due to a different reason --- bad environment, bad specification, bad coding, time pressure, no requirements, etc. etc. etc....

In every interview of mine, I ask the test engineers who are applying for the job about any defect that they'd have leaked earlier. And to date, most of them have said that they have never leaked a defect in their entire life!!! This is coming from testers who have an experience of 6-10 years in the Software Testing Industry.

Do I see an entry here for the files of Ripley's believe it or not? (Personally speaking a tester who's never leaked a defect can be equated with a developer who has never had a single bug filed against his name).Unbelievable!!! Truly, Unbelievable!!!

The truth is that even experienced testers leak defects. And only we know about the defect that we leaked. And we have to ensure that we have to remember a leaked defect all the time to remind us that we are also vulnerable, so that we will at least try to avoid leaking defects in the future!!!

Fake Tester's Gyan (of course, the gyan giving is very important too)

1) Admit Blame --- Yes. Admit blame at least to yourself, if not to the entire world!!!
2) Shameful, it is not --- Though you might feel some shame in admitting a defect, trust me, it’s not. What’s actually shameful is NOT TO ADMIT IT TO EVEN YOU!!!
3) If I leaked defects, am I a failing tester? --- A common misconception is that you'd seem a failed tester to your peers if you admit it. You are not failing. You are the only one speaking the truth and you are sub-consciously scaling the success peak by your honest admissions.
4) It takes Guts. Do you have them? --- It takes guts to admit a defect you leaked. Am very sure that you do have a leaked defect. But do you have the guts to admit it?

If you are mentally strong enough to admit to a defect that you leaked, please feel free to share it on the Comment section below. If you are not bold enough to share it with the world, spend 10 mins in retrospection, admitting it to yourself!!! To own up to yourself about blaming self for a leaked defect makes you a better person; and a much better tester in the long run!!!

Happy Admissions, if you dare to admit!!!