"Some birds aren't meant to be caged, their feathers are just too bright"- Morgan Freeman, Shawshank Redemption. This blog is from one such bird who couldn't be caged by organizations who mandate scripted software testing. Pradeep Soundararajan welcomes you to this blog and wishes you a good time here and even otherwise.

Tuesday, July 24, 2007

Let the context drive and yet you be the chauffer

_ marketing starts _

My next public workshop on testing skills is this weekend ( 28th July 2007 ) and I am getting excited. Many testers who got in touch with me over the past are saying, "I will surely attend the next one" and they said this last time, too. I have been asking a question to myself, "Who would attend this workshop then?"

That's funny and I enjoy asking such questions to myself. In case, you are not the one who says, "next workshop", here are the details!

_ marketing ends _

Some testers have liked my blog so much that they have certain expectations from my blog and when I talk about myself in my blog, they get so irritated and ask me over chat, "I come here to read and learn something about testing that can help me do better testing, I don't want to read about you and what you did and all your marketing stuff".

You don't get to see a live cricket match or a Formula 1 race without you being forced to watch the advertisements in between. Anything that you want to keep watching is a business opportunity to someone and they place advertisements and that's marketing for them. When I write about myself, its important for you as my reader to understand that it's one of the way I look for self inspiration whenever I am down. If you want to read something fabulous in this blog, I hope you allow me to read something that I want to read to get inspired and write a post that appears to be fabulous to you.

OK, this post isn't a debate about the above topic but I am sure, I did a mistake in setting the wrong context for what I want to say under the topic "Let the context drive and yet you be the chauffer"

Believe me, I wanted to set a wrong context and that was intentional. Yesterday night, a tester/cum test manager Rahul Mirakhur, the Apple Macintosh Geek you can bet on, had a status "context matters..." and the idea of this post came alive. So here is a context...

When a police man is informed over radio about an accident that took place and he rushes to the scene and he discovers two cars damaged and appears to be a head to head collision. What would your first question be to the people who are fighting with each other if you were the policeman?

All the policemen I have seen try collecting information about the context and try to make a judgment or take an action based on the context information he has.

What if you were one among the two, fighting against an idiot who rammed his car head to head and you discover that he doesn't posses a license to drive the car, yet the policeman arrests you without asking any questions?

Would you not be terribly disappointed?

If you would be then I think you value context a lot.

Now time for you to answer my question: Why does many testers, leads and manager not think about the context information they need to collect ( more than what they think they have collected ) to take a better decision, especially when they have been going wrong. ( If they don't recognize that they have been going wrong, is a bigger problem, of course)

The policeman who arrested you, followed a best practice that states: A guy in an accident scene who is shouting on top of mouth is the culprit! Are you OK with such best practices?

As rupee is gaining Indian business leaders are planning to make all of us work 9 hours a day for 6 days and no more Saturday off. I thought growing economy means things would be more smooth :) [ Refer to this article ]

Why cant we fight back saying, "Hey we will do our work in a more skilled fashion and that's what would result in cost v/s value to our customers in North America and Europe and it's a win-win situation"

Ha ha! I am sure we can never say that because Best Practices drive us. A person who has worked with company X for a long time and implemented a process or style of doing things is hired by Company Y and he tries the same in Company Y but fails. Why?

There are good practices in Context but there aren't best practices!

Ramit Manohar, one of my favorite thinkers on testing from India reports to Vipul Kocher, the President of Indian Testing Board and the Co-Founder of Pure Testing. If I were to practice humility, it has to be looking at Vipul Kocher.

Ramit, during our meet, started saying about a question he often asks in interviews that he claims to challenge testers. I interrupted him and said, "Ok, let's assume that you are interviewing me and why not I try taking up the challenge?"

So, here is the question he asked me: You are riding a bicycle. A pedal comes out. What would you do?

This isn't a testing question! [ that was how most of the testers whom he interviewed reacted because they didn't think of collecting context information about why someone is asking such a question in an interview supposed to hire a tester and ended the conversation there]

You might want to know how a context driven thinker and a skilled tester: clears traps, solves problems, gains situational awareness, learns new things, asks questions, makes a suggestion, proposes solutions, a lot more ...

Here it goes...

What aspect of my thinking would you want to see by making me answer this question?
Flow of idea, lateral thinking, situational awareness, collecting context information ...

Whom are you referring to when you say, "you"?
It's you Pradeep!

Why would I be riding a bicycle when I have a bike and a car?
You are in a race

What do you mean by a race?
Something like Tour De France

Where am I riding a bicycle?
On the busy streets of Bangalore

What do you mean by a bicycle and bicycle pedal? ( I asked him to look out of the window from the coffee shop and showed him what bicycle means to him and the pedal that I am aware of as one was parked outside)
Yeah! That's similar to the one that I have in mind

What speed am I traveling in and are there brakes that appear to work when applied?
Ha ha! How fast can you travel in busy streets of Bangalore? ( I accept, being in Bangalore, that was a stupid question :P ) The brakes are working fine.

Is someone chasing me?
There are people trying to overtake you to win the race.

Does this mean, I am leading the race?

Is there something important I missed asking or might add value to me taking a decision?
Yes, there is a bicycle repair shop nearby!

How important is winning the race to me?
You should say that!

Can I assume that I am not bothered to win the race?
There is a huge prize money for the winner.

I dont want to lose that. However, what is it for a person not finishing the race?
He will be shot!

Wait a minute... Are you interviewing me when I stopped the bicycle after the pedal came out? [ the smartest question, in my opinion]
Ah! No

How far is the finish line from the place where the pedal came off?
Not too far!

Is the pedal made of Gold or has a value bigger than the prize money?
Ha ha! I don't think so.

Let me stop it here (although I think you should meet me sometime and listen to the entire conversation between me and Ramit which might excite you, too)

I shall de-brief what might have happened if context related information was not collected, taking the above exercise.
  • I might have been shot, if I had not known that the person finishing last in the race would be shot.
  • I might have tried too hard to win the race for the prize money whose value is lesser than the pedal that came out.
  • A "bicycle" might be a brand name of a car where there was a nasty pedal fitting that restricted the performance of the car. Had I assumed it to be the bicycle I know, I would have not cleared the trap that Ramit *might* have set.
  • Had I not asked an important question, "Is there something that I missed to ask?", I would not have found that there was a bicycle shop nearby that might help me in taking better decisions.
  • Had I not discovered the speed at which I am traveling and the brakes not working, I might have taken a different decision, all together.
Ramit was so excited and enthused about the conversation we had that he keeps mentioning about me in all the corporate training he does. I am grateful to him, not because he mentions my name everywhere but for giving me an opportunity to practice my skills.

Every question might lead to an answer or to another question, and every answer or question that raises from a question, would lead to asking a potential question that discovers more information about the context.

Why would you want to go to a doctor who never asks any questions nor collects any context information to a patient and starts operating the moment patient says, "head ache"?

If you want the doctors who treat you to be context driven but you are hesitant to be context driven as a tester, you better try not feeling guilty about it!

-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

"Pradeep's first language is not English--his first language appears to be testing." -- Michael Bolton

Monday, July 16, 2007

Why is testing monotonous? The unspoken truth!

My previous post ( Becoming a developer, who is less disturbed by a tester [ in 3 pages ] ) gave me a little surprise when a tester came back saying, "Hey you are helping developers, doesn't that make testers job difficult?"

Another surprise today: 2 testers who were online, pinged me to say that they were doing a monotonous job. When I questioned them I was excited with the work that they had in their hand.

Take a look at one of the conversation:

tester_a: upgrade testing is awfully boring. Any views on this?
pradeep: upgrade testing, what do you mean by that?
tester_a: testing upgrade of a product from older to latest version
pradeep: wow! It's exciting.
tester_a: what would make it exciting?
pradeep: Thinking of what kind of update issues, the product or users might face.
tester_a: there are no issues. it either works or doesn’t. its not scenario specific either and with around 45 platforms to support and 6 methods of upgrade ...its monotonously boring
pradeep: ok, let me give you a list of tests that I might want to test, if I am asked to find important problems quickly.

*What bores a tester always interests the user*.

tester_a: ahan!


1. What if the product while it's getting updated, is hooked off the network?
2. What if an update file is corrupted?
3. What if an update file is infected with virus?
4. What if an update file for a specific platform is fed to another platform?
5. What if your reboot the computers while it's updated?
6. What if the server is reset while a client is updating?
7. What if an application on a client interrupts the update?
8. What if an upgrade fails? What more problems could be hidden with it?
9. What if an auto update and a manual update is attempted in parallel?
10. What if software is attempted to uninstall when an update to it is happening?
11. What if more than one method of upgrade is initiated from the same client with different instances of the application?
12. What if there is an upgrade of the platform happening while the product update occurs?
13. What if the resources required for the upgrade platform are squeezed?
14. What if the update file has wrong information in it?
15. What if the file date is changed to a date than the current version yet it has the latest update?


Now, doesn't that sound creative work?

tester_a: doing it on 45 platforms with 7 different ways = 45*7 might not be interesting!!!

a single platform ? Yes sounds "WOW" :)

pradeep: well, let me explain, How I would strategize...

Perform tests on one platform, first. Note the important problems. Look for similar problems on other 2 platforms. If they are serious problems - report and disqualify the build/release/update/whatever?

I would also negotiate with my manager for another resource or two who could help in getting this done effectively by saying, "I fear that any tester to my knowledge might find it tough to do all of that"

If you have been given time, its better you do it with passion.

*The company never thinks it is doing a monotonous job of paying you salary , every month!*

tester_a: lol that was a good reason :) thanks buddy ! You are great help at time like this :)
pradeep: Here is something that you might want to think: Soldiers are asked to work very hard even when there is no war. If they think it's monotonous and quit the job, we die at enemy's hands. There is a soldier guarding you somewhere, far away, and you better not call anything monotonous.
tester_a: hmmm
pradeep: Isn't that true?
tester_a: it’s a debatable topic
pradeep: ok, I suggest you debate with yourself on that.

_ End of chat excerpt _

Why is testing monotonous? The unspoken truth!
  1. It's made so by testers who *might* not be able to think or be creative.
  2. It's made so by testers who *might* be lazy to run those tests.
  3. It's made so by testers who *might* have not learned something that they could apply to the work that they do, to see a different result.
  4. It's made so by testers who *might* lack passion to test.
  5. It's made so by testers who *might* want to jump to development and needed a reason that others could accept.
  6. It's made so by testers who *might* not want to try any new test other than the script that they have been given.
  7. It's made so by testers who *might* want a reason to jump to another job.
  8. It's made so by testers who *might* lack motivation to test.
  9. It's made so by people who *might* be claiming themselves as testers but aren't.
  10. It's made so by testers who *might* not have skills to find bugs.
  11. It's made so by testers who *might* claim to know testing after knowing definitions and terminologies without knowing how to apply or practice them?
  12. It's made so by testers who are promoted as a test lead and *might* be happy thinking, "hurrah, no more test execution" and go completely wrong with their career in testing for thinking that.
  13. It's made so by test managers who *might* not want to allocate more resource for a huge task and yet get it done with a few testers sacrificing the quality and value.
  14. It's made so by testers who *might* want to do exploratory testing but are stuck in scripted approach.
  15. It's made so by testers who *might* be doing tasks with same mistakes.
  16. It's made so by testers who seek guidance from a person who claims to be a tester and who doesn't know much about it and yet offers great advice to his junior to learn tools like QTP, Winrunner, Load Runner, Silk... to get out of monotonous work. ( Actually, running tools for a life time and being a toolsmith and yet claiming to be a tester, is monotonous)
  17. It's not testing that is monotonous, it's testers thinking that is monotonous.
  18. It's made by testers who monotonously say "testing is monotonous"!
Those who question, don't experience monotony. Those who question, experience testing.
If you experience monotony, you aren't questioning. If you aren't questioning, you aren't testing.


( A couple of days left before the registration *might* close for an exciting workshop on testing skills. Look for the announcement in the left top corner and register before I start saying, "Sorry" )

-- Pradeep Soundararajan - pradeep.srajan@gmail.com - +91-98451-76817

"Pradeep's first language is not English--his first language appears to be testing." -- Michael Bolton

Monday, July 09, 2007

Becoming a developer, who is less disturbed by a tester ( in 3 pages)

Some articles might have made us go crazy about it. For an author, it is a very different experience when the article he is writing makes him go crazy. This article, is one such that excited me and got me more excited when I shrunk first half of the name of article using first letters of the words and leaving the rest to form ...

Pass it on to your developers! [ It's important for them to know this information ]

Pick your copy of BAD WILD TESTER now for FREE!

-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

"Pradeep's first language is not English--his first language appears to be testing." -- Michael Bolton