Letter to myself

Dear Pradeep,

Greetings!

I have been with you all this while and shall continue to be with you. I am enjoying each moment you enjoy as a tester and also each moment that you don't enjoy as a tester. I am sorry for enjoying those moments which you think you haven't been enjoying. I am sure you'd be interested to know why and how I have been enjoying those moments that you haven't been.

First, let me list the thing that you haven't been enjoying:

• Whenever and wherever you write about test automation, a handful of readers tend to think that you reject the idea of test automation and they write harsh e-mails to you.
• Whenever and wherever you write about certification, the certified tester community attacks you over e-mails/phone calls that you and I are spoiling the craft.
• Whenever and wherever you write about programming skill for testers, another handful readers think that you are suggesting testers not to learn programming.
• Whenever and wherever you write about tools, most testers think you are referring to test automation tool.
• Whenever and wherever you write about yourself or your experience, a set of people think you lack humility.
• Whenever and wherever you write about exploratory testing as a skilled activity, a set of people think "no tester would do be able to do that".
• Whenever and wherever you write about ideas to solve a problem than giving a one line answer, a set of people think you don't know how to solve it and is faking what you know.
• Whenever and wherever you are writing about testing being an excellent thinking job, a few people think you are trying to paint a picture that does not exist.
• Whenever and wherever you - do bad testing, fail in testing course like BBST, you feel intimidated by more skilled people than you, you feel bad about not having learned or practiced those things that helps you become a better tester, you fail to give enough respect to expert testers time, etc...
  

In this context, I'd like to remind you of a learning you had from Michael Bolton: There are some things under your control and there are other things that are not under your control. Taking advantage of things under your control, as a tester, is essential to clear traps and it might also lead to gaining more control. To take advantage of things under your control, you first should realize what are the things you control.

I also remember that you had made a note in your Moleskine of Saurav Ganguly's television interview where he was asked: How were you able to make a great comeback to the world cup cricket squad after being axed for poor performance? His answer: I didn't worry about things that are not under my control ( media critique, jokes on bad batting performance, e-mail forwards about my performance, people gossiping about it ) but focussed on things that are under my control ( Practice, skill enhancement, consistent batting record in Ranji trophy)

Similarly, you don't have a control over the thoughts of people thinking whatever they think after reading whatever you have written. You have a control over what you write and you have a control over the way you write it.

Your testing has been influenced by a lot of experts but not all have similar influence. They haven't seen great testing to appreciate the things you are sharing and I doubt if all those who witness it would be influenced by it because it's hard work and high skill demanding.

• Not all testers want to do great testing
  
• Not all testers know they are doing bad testing.
• Not all testers want to know they are doing bad testing.
• Not all testers want to know more about testing.
• Not all testers know what skills to gain and practice.
• Not all testers agree to be context driven.

Here are three questions ( like the Monty Python and the Holy grail bridge of death piece you enjoy )

1.Whom are you serving through your writing?

I am sure your ongoing struggle is in understanding that. Let me help you with what I think about whom you are serving - You are serving those testers who look for better thought process and those who enjoy the better thought process and those who think you have a better thought process.

2. Who asked you to serve them?

I asked you to do that!

3. Why haven't you been enjoying some moments that I have been?

You want all testers to do great testing although you know its not possible. Some people question your idea of "great testing" because they already have an idea of "great testing" and it conflicts with the idea you have. You are able to demonstrate that their idea of "great testing" lacks critical thought as your idea of "great testing".

By the way, your idea of "great testing", is not yours but of those people who have influenced you. You have just subscribe to those ideas and are contributing to it in different forms. I have occasionally witnessed you doing bad testing and I am sure I would see that in future, too. Do not forget that you are a human and your ideas are fallible. I know bad testing and bad thought process irritates you, even if you are the one who is doing it.

I would love to see you doing things that are under your control - learning, reading, writing, bettering your skills, helping those testers who enjoy the thought process that you enjoy, speaking, coaching and mentoring.

Your power to influence testers is limited. Limited to the ones who don't want to limit themselves. So do unlimited things under limited time that you and I will be here in this world.

I will be with you forever, enjoying everything you do from great things to not so great things. Anything you do is great to me.

I will write to you whenever I feel a need for it. This letter is personal, just between you and me.

"Here is a way to test if your mission on earth is complete - if you are alive, it isn't" -- Richard Bach

Yours truly,

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

"The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it." --

Automation replaces humans - The truth about what kind of humans it replaces

I often meet people who claim to be "automation testers" and I love and hate to argue with them about test automation. The more I meet such people, I am getting confident about making a conjecture that more than many people who claim to be doing test automating in India and other APAC country testers I visited, are doing it without knowing it or without wanting to know it.

Here are the things they say:

• Test automation replaces manual testing.
• Test automation is faster than manual testing.
• Test automation is cheaper than manual testing.
• Test automation is more reliable than manual testing.
• Test automation removes the monotonous work of a manual tester.
• Test automation provides confidence that the product works.
  
• Test automation is the future.
• Test automation is better than manual testing as a career option.
• Test automation tools provides Return On Investment.
• Test automation can find a lot more bugs than a manual tester.
• Test automation provides more job opportunities.
• Test automation is a way to go about testing.
• Test automation is about converting manual test cases to automation.

Lets look at some of them based on the conversation I have had with such people saying one or more of the above or the questions I'd like to ask you:

Test automation replaces manual testing and Test automation is the future

There are two planes standing there. One of them was tested by a trillion scripts that flew the plane for 400 hours and the other was tested by those 4 humans, flying 100 hours on it. If you were to board one of them, which one would you board and why?

None of those great human beings who said, "Test automation replaces manual testing" said, "I shall board the plane which was tested by a trillion scripts" and instead said, "I will take the plane that humans tested because I feel safer throughout the flight"

So did test automation replace manual testing even for those automating tests?
Test automation is the future of what?

Test automation is faster than manual testing & Test automation is cheaper than manual testing

Here are some statements I make. You can pick ones that makes most sense to you:

A. My Toshiba laptop runs faster than a McLaren Mercedes Formula1 car.
B. My Toshiba laptop runs faster than my old Acer laptop.
C. My Toshiba laptop runs faster on an XP than on Vista.
D. My Toshiba laptop runs faster than that horse which has a broken leg.
E. When someone needs help and I need to run to them, I use a test automation tool because that's faster.
F. QTP license is cheaper than hiring a 5 year experienced skilled tester.
G. QTP is expensive than Winrunner.
I. QTP is cheaper than a Ferrari engine.
J. Winrunner is cheaper than a business class ticket from Bangalore-Toronto.

Option C and G makes most sense. Why? Why not A , D, E, F, G, I, and J?

"Well, option C and G makes most sense to me because you are comparing the same Toshiba laptop when Vista and XP runs on it AND you are comparing two testing tools in G"

Is test automation [ using a software or a computer ] faster than humans to those who say that?
Is test automation cheaper than those human brains who claim to create it?

Test Automation is more reliable than manual testing

I first heard this eye opener, insightful idea from Michael Bolton , "People write code to find bugs on another code. They write code that is buggy which claims to find bugs on another code" and "Writing test scripts is another development project . Most of them don't realize that they are running two development projects in parallel and hence their main development project suffers."

So is test automation reliable than manual testing to those who write code that test another code?
We humans are fallible and all things we create are likely to be fallible, too. Test automation scripts are not excused by God to feel "All test scripts don't have bugs".

That doesn't mean human testing is more reliable. It means, anything done by humans is fallible. When you depend on a fallible thing that a fallible human created, you might not want to talk about reliability there.

Test automation removes the monotonous work of a manual tester

Why is testing monotonous? The unspoken truth!

Test automation is better than manual testing as a career option

Well, people think by becoming an automation tester they aren't doing manual testing. Here is what I have discovered - There are more people who claim themselves as automation testers in India than those who claim to be manual testers. So, let me know which is not manual testing? Can manual be termed as anything that does involve humans?

Lack of skilled testers at least has helped me grow phenomenal in my career. I am not THE skilled but I claim to be one of them and there might be very few like me and not many in India.

Test automation can find a lot more bugs than a manual tester & Test automation provides confidence that the product works

Yes, test automation is very intelligent. If a script is programmed to catch a bug when a value exceeds 5, it can also notice that the value did not exceed 5 and pass the test but the screen went blue for a while. If after all scripts have run and there aren't any bugs found, the test automation suite will alter its values and run once again to catch bugs. As the scripts run over and over again, the scripts learn the product well and if the management needs to take a decision to ship the product they would come near the script and say,

"Oh magical script, I want to ship this product. If you think it's a bad idea to ship now, speak out else remain silent"and then they listen to the script and decide whether to ship or not.

Yes, we are dumb. We can see a numerical value not exceeding 5 and pass the test case but also we can't spot the screen becoming blue for a while and do not report that as an issue while running a test that we claim to pass.


Test automation is about converting manual test cases to automation

Oh wow! So, I can't write automation scripts without writing cases and executing it at least once by my own? And if I write, many might cry "Foul".

Well, test automation scripts are just another program as the program it tests. Did developers have something they did manually before they wrote the code that you test with your manually converted automation test scripts?

Test automation tools provides Return On Investment.

Ok, so here is the industry standard of returns on a tool: For every $500 invested on a tool, a good ROI is about the tool helping the team find 50 bugs.

So, a good ROI for $9000 tool = ( 9000 / 500 ) * 50 = 900 bugs

If that doesn't make sense to you then what is the Return on Investment for a tool?

Bugs? Customer appreciation? The number of testers who get fired? The cost savings of hiring 10 skilled testers v/s the cost of buying the tool? The value that the tool brings to the testing effort? Tons of documentation produced? The added cost of training? The added cost of support? The added confusion that prevails? The number of fake experienced testers who apply to the job of a toolsmith?

Test automation is better than manual testing as a career option

Test automation, at least in India, is more chaotic than the so called manual testing. Hardly any tester knows why they are automating things. You may join any forum where testers are active discussing tools and automation, you'd see questions that the help file of the tool has answers and you would discover replies to such questions that is sometimes horribly wrong and yet the person who asked the question says, "Thanks" and the chaos continues.

There is more chaos among so called automation testers than so called manual testers because the so called automation testers form a huge community than the so called manual testers. More people with lack of insightful ideas means more chaos.

Want to know some useful information about automation or want ideas to think more about it?

Cem Kaner prefers to call most of the automation activities that most testers do as Computer Assisted Testing and I couldn't find evidence to refute the idea. I think it is a great idea to call it "Computer Assisted Testing" and you would know why it is a great idea if you go through this article by Cem or the PDF version of it.

So, all of us irrespective of calling us manual or automation testers do Computer Assisted Testing.

I know of an article written by James Bach that made many people who claims a lot of things about test automation feel guilty and I am sure if you have reached this place reading this post of mine, you'd be interested at reading James Bach's Test Automation Snake Oil - the paper or the slides .

I also know of a blog post from James - Manual tests cannot be automated and Shrini's post on A Mystery called automated testing.

Here is why we do different things in testing such as writing test code, executing test ideas, investigating, diversify approaches, think of different techniques, use heuristics, use oracles, Explore... - because each of them add different kind of value and each of them helps in finding different kinds of information or helps us ask new questions AND NOT because something is better than the other.

There is lot of thinking, reading and writing, I and you require, to know about test automation or about testing. The lazy ones don't get to learn and continue to spoil our craft because they don't stop writing, just like me. [ It's intentional ]

I know I haven't answered a question that you might have in mind but that's intentional again.

Update: Here is Jonathan Kohl's awesome interview about the same topic. Thanks to Konstantin for pointing it out through a comment.

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

"The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it." --

The Bangalore Roti Curry! Now comes with free* testing lessons

Yesterday, I presented a guest lecture on "Questioning Specification and Requirements as a skilled tester" at Edista Testing's newly launched, really unique career program, which I think, can be titled as "Keep learning software testing and we'll keep supporting you to do that" as they intend to keep track of the progress of one's testing career, knowledge and skills even after the completion of the program or after the placement.

One hour after the guest lecture, I hit the treadmill at a gym nearby my home. I love pace walking over the treadmill. Once I get my rhythm , I start thinking about something that doesn't make me focus on how tired I get or how long I have been on a treadmill. Yesterday's treadmill thoughts were about questioning specification, requirement, process, policies, rules, guidelines, best practices...

The common thing about the above list is, "Someone says it, others follow it". Topic I chose to think on the treadmill was interesting enough to help me burn a lot more. I guess for people like me, thinking about following a requirement/rules/policies/process/best practices without questioning burns more calories than running heavy on a treadmill for 30 minutes.

After the workout, I dropped in at a nearby popular and reputed food joint for dinner at Bannerghatta Road, Bangalore.

I bought a token for 1 plate of Roti and curry ( Indian bread ) Cost: 16 rupees. After I got the token in hand, I realized it would not be sufficient and asked if I could get an extra Roti. I had to pay 10 rupees to buy an extra Roti token.

While eating one of the two Rotis, I realized that the curry isn't sufficient for the next Roti and I asked for more curry, I was asked to pay 10 rupees more for extra curry that is of same quantity provided to me the first time.

So here is the interesting thing:

One plate Roti and curry is: 16 rupees : [ 1 Roti + 1 set Curry ]
If I buy an extra Roti and Extra curry: that's 10 + 10 = 20 rupees
Total: 36 rupees [ 2 * 1 Roti + 2 * 1 set Curry ]

If I buy two plate Roti and curry: 16 * 2 = 32 rupees [ 2 * 1 Roti + 2 * 1 set Curry ]

I went to the hotel supervisor and said, "I have never come across any hotel other than yours which has two different prices for the same quantity and item served if purchased in a different order. Is that intended?" and then explained to him the sequence in which I bought Roti and Curry. You might not believe this: He nor the other staff knew that they had been charging customers different rate for the same quantity they buy an item based on the order in which they buy things.

This certainly surprised their staff and I could witness an argument over the issue among other staff members. There was excitement over the issue and I enjoyed the argument between them.

Supervisor of the hotel then assured me that they would fix this issue after consulting the hotel manager and thanked me with a smile for bringing this up.

I was happy. As a tester, I questioned things and provided them information about their service with evidence. I handled it politely and helped them understand how illogical it would sound to people and how their credibility is at stake if they continue to do so.

If I hadn't questioned at the logic, or their menu, or their process, or their specification, I wouldn't have helped them understand something was seriously wrong - because they seem to be concerned to not do anything wrong as it could affect their reputation. They are into this business for at least 5 years and they hadn't realized what rule they set could conflict with their own menu rates.

When customers say "We want A,B, C, D, E, F", they are less aware that A could conflict with E unless we ( testers ) help them understand and that's our job. If we (great testers) don't question requirement/specification/process/rule/guideline/best practices, and the customer by himself finds B conflicts with D at a later stage, he might think of us as fools and maybe get our butts fired.

"If testers aren't questioning, they aren't testing. If testers aren't testing then they aren't testers anymore".

In the Roti Curry story above, I think there is another lesson hiding. As a customer of the hotel, I realized I wanted more, only when I got some bit of it - which means I didn't know how much I needed to buy till I saw some sample. If someone were to have collected my requirement/need, I would have stated something and changed it because I am not sure what I want.

There are a lot of customers who are not sure what they want and if we ( great testers ) are to follow a document that was prepared so early in the project before the customer could see something, we would never be doing what we should be doing. Testing is *not* satisfying a customer but providing information to help the management or customer take informed decisions. The information we provide could be bugs, assessment of risks, questions we have, answers we found...

Little does the hotel know that testing lessons are for free when people buy Roti and Curry.

Laugh (if you want): Research Doctors at National Health Research Institute are recommending to take a minute of every day, especially for those in software testing, to laugh out loud at those testers who don't question the specification/requirements/test scripts/test cases/process/best practices.

It is found through their research that the health condition and testing has had a significant improvement by doing so. Researchers also encourage laughing at yourself, if you are one among the testers who don't question.

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

"The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it." --

Progress Report 2007 of Pradeep Soundararajan

Happy New Year wishes to all my readers.

It is exactly one year since James Bach officially hired me to represent Satisfice Inc in India. James Bach wrote in his post Satisfice India, "A Satisfice tester, (as my brother Jon, at Quardev will tell you from working for me for 18 months) is expected to be quantum cut above normal testers. We achieve that not through wishful thinking, but through study and practice. A Satisfice tester is always ready to be challenged about his work".

So here is my progress report for 2007 that you might want to go through. When I wrote the report, (which took me a long time to compile, think, laugh and cry as I remembered each moment of 2007) I understood why I think I am one of the most passionate software tester without excluding the fact that I am living among other passionate testers. I finally feel eligible of what credit I got one year before, this day.

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

Second time, a company in India wants to hire testers in a non traditional way

What is the company looking for?

As a Test Manager of the company, I am looking for 3 testers, each of whom has spent at least 2 to 5 years testing and learning diversified things in testing. I want to challenge the tester in a permanent position in the company I work for, to solve complex software testing problems, whose main focus would be to question testability and supportability of products and write tools to augment testing activity.

Interview

The interview would typically be a telephonic followed by one full day at office premises (probably a weekend) in which you would be given a mission or different missions to achieve by the end of the day. You would face questions based on your testing activity at the end of the day.

I am not listing the skills you need to have but I know whether I should call you for an interview or not through:

1. Write 2-3 pages about your testing experiences so far. If you reveal any confidential information, although you might be too good, I am not taking the risk of calling you for an interview.
2. You may want to attach your CV or anything you think might interest me to call you.
   
3. Fake experiences would be reported to police, so don't risk yourself.
4. Don't mention, even if you have certification in software testing, because it just doesn't help/ better any chances nor worsens. I intend to hire you for your skills of testing and not your certificate that plenty people found it easy to clear.
   

If you are a fresher, Test anything over web and send me your report. I might still be interested to foster you.

e-mail me your reports to testwithpradeep@gmail.com

Here are some highlights of working with me:

1. All testers who report to me have been enjoying freedom, which is very important for testers.
2. All testers who report to me haven't been asked to do documentation that's wasteful or for the purpose of documenting to follow a process.
3. All testers who report to me have got a chance to be questioned on their work quality and some have been rewarded once they practice the changes suggested and also see a value in doing those changes.
4. At least one tester who reports to me started to blog about her testing activity and the thought process that went through to find some bugs ( without revealing the confidential information, of course)
5. All testers who work with me have had freedom to challenge me (without bothering if I am their Manager or not) or my ideas I propose to test without bothering if that would affect their credibility with me provided they are open to learning and unlearning.
   

If all above looks tough to you and don't want to put in that much of hard work to get a challenging testing role, Yahoo, my filter works.

Here are some traditional stuff:

1. Your designation might be a Senior Test Engineer or Test Lead who reports to me (but don't bother too much about that right away).
2. Your pay is decided by the budget allocated for these positions which is in par with industry standards calculated based on some formulas that I am not aware of. Post observing your performance, your pay is not decided by any formula but solely your performance and the company's performance in market.
   
3. You will be required to join ASAP or within 30 days of the date of offer.
4. The work location would be Bangalore.
5. The 10 year old US based medium sized company I work for respects and value testing, and post me coming in, I see more recognition towards testing given by the senior management.
6. There might be some traveling opportunities in Q3 2008 but no guarantee and don't get attracted just because there might be a traveling opportunity.
7. You may be a tester from any domain as long as you don't have a mental block to learn new domains and technologies.
8. Send in your entries before others steal your chance.
   

The good news for those who are excited about this is, I am sure very few people would dare to compete and hence the competition wouldn't be that fierce. So the more excited and curious you are when you read this, the more likely you might be hired.

So, who are those 3 testers among you who would get this unique opportunity that probably other Indian companies might not offer.

It takes courage to challenge and skills to tackle the challenge. I am calling the skilled and courageous to work with me. Get in touch through testwithpradeep@gmail.com

For those of you who want to know what traditionally companies ask for, hit MonsterIndia or Naukri websites and search for tester job openings. Not to my knowledge anyone asks for skills of testing from a tester, instead would focus on tools knowledge or horribly trivialize manual testing and process knowledge.

Hey look, at least some part of Indian testing is changing with more focus towards human skills! Are you left behind?

You might want to know, when was the first time a company in India wanted to hire a tester by non traditional ways... Simple, when the company I work for hired Pradeep Soundararajan ( that's me ) as a Test Manager at his age of 26 and helped him become the youngest Test Manager of India.

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

How to show product quality? - (Uncensored Version)

A Tester's Personal Bug Diary & Notes

I was wondering if there is a way that I could spill some of my secrets of finding a lot of bugs in anything I test to other testers who read my blog. I think, I finally found a way in which, I also could tell, how some experts with whom I interact are fantastic bug hunters.

It's not a big deal and it is simple enough for you to follow, if you intend to be wonderful bug hunter.

I got this idea after I did testing for a new application that a company developed and claimed that is tested enough gave it to me to check for some bugs that they might have missed.

It was a very important session both for me and for the company. Another interesting thing for me is that the company had sent their developers on some work to my office and I had a chance to make them sit with me while I was testing. Whenever I found a bug, I said a story. Here is one such: "I have not come across a user who would want to hover the mouse all around his monitor to spot that button, which is an important action that he would want to do after entering so much data. Do you know of anyone who would like to do that?" ...

18 important bugs in 32 minutes of testing and I met the mission that I set for myself - Find important problems, quickly. I said to myself "Wow Pradeep" and then added to it, "How could I do it?"

Rapid Testing taught me to observe patterns, carefully and decode information from that can be of great help and yes it did come handy while I observed the pattern of my tests and bugs that I found. I must admit that 95% of the bugs I found in that session are from ideas that I had already developed testing other applications over the past and by registering the pattern in my brain.

And here is an important question I asked to myself: "Pradeep, can you do this wonderful job all time?"

Here is the answer: No! Not all time because it depends on a lot of different factors, out of which some I can control and some I can't.

The pattern and behavior of our own brain is something that I feel is tough to understand. It responds to the queries we put based on the situation in which it is at that phase. If I am upset over something and I put a query to it, it doesn't retrieve immediately or it might have a performance issue at that context but the wonderful brain needs something to rejuvenate.

What can that be?

"Hey Pradeep, you said you found a way to help testers become fantastic bug hunters and now you try answering something else?"

A tester's brain needs questions and ideas and to rejuvenate, motivate, push, think... it needs to look at your own work. No, my idea isn't to carry a video of all testing you do but a database, for sure.

What kind of a database could it be?

Presenting to you, A Tester's Personal Bug Diary & Notes ( right click, save and open )

I pull my ideas to find a lot of bugs from my database that currently resides on my brain. I am excited about the one that I created and I would be using it and someday, I can just filter the results based on the application I test and find many important problems in a few minutes. I am sure my clients would be willing to pay a lot of money as they see cost v/s value.


Off topic: I added a Copyright section to my blog that says: I, Pradeep Soundararajan, own the copyrights of all my writing in this blog. If you want to reproduce a part or any of my posts anywhere on the web provide a link to the blog or a specific post or if you want to reproduce it as a hard copy, please send an e-mail to pradeep.srajan@gmail.com .

Plagiarism (stealing of posts and not owing credits or claiming to be authors) of any of the content or ideas obtained from this blog would be reported to Cyber Crime Department and my tester friends network is wide enough that ones who plagiarize have lesser chance of not landing in jail.

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

A good tester clears traps. Who are you?

There is no standard definition of a "good tester" to my knowledge but I am sure there are ways to say if I am doing a good testing. I self certify as a "good tester" and I *think* I am respected because my standards are higher and growing!

Years back, I fell into a lot of testing traps and I fall into fewer testing traps today. The traps that I fall in decides how bad my testing is. It certainly takes time to recover from the traps and hence I lose time which otherwise could have spent adding value to the project.

Customers aren't happy to pay for the time we spend to recover from the traps we fell into. There are times where we ourselves set traps (and jump into it) and there are also times where others or situations sets a trap. Whatever is the source of the trap, we fall into it and the biggest and dangerous of all traps is this: To not realize that we have fallen into a trap or to be reluctant of having fallen in a trap.

Here is an exercise that I worked on, which I think, helps in demonstrating the art of clearing traps in testing. I would call it : 100 questions in 20 minutes - The Art of clearing traps in testing [ PDF file : 104 kilobytes ]

Wishing you a good learning experience!

Do you think I had a specification or requirement document when I took up the exercise?

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

The story of a monk who sold bugs!

In January 2006, I wrote an interesting post in my blog that became one of the favorite e-mail forward among testers in India. To my disappointment, when I got the forward e-mail from a couple of people, I could see different names as authors in it and I never got the credit. I bet no one can make the kind of creative grammatical mistakes that I do and its always easy to spot my writing. Also as Michael Bolton pointed out in software-testing list, "Pradeep writes from heart".

Fearing those idiots who did not owe me credits I didn't want to write such stories that could make another interesting forward with a claim that they are the authors. I am no coward and most important of all, I don't want my blog readers miss such stories that I have in mind. So here is a story that I think that has gone weeks of thinking:

The story of a monk who sold bugs written by Pradeep Soundararajan [Idiots and fools can change it to their name if wanting to forward the story]

Once upon a time, not so long ago, a monk set out looking for a job in India that could help him earn enough to feed his family. Monk knocked the door of a few software companies and by God's grace, a company did consider him for an opening in testing that they had.

The monk was new to the software industry and had calculated his monthly salary by dividing the CTC ( or cost to company per annum ) by 12 and felt happy about it but when he received his first pay check, he did come to know that maths in software industry, especially when it comes to salary is different. It was not possible to run his family with the monthly pay check he received and hence had to find a way to earn more.

Looking out for another job means, taking time off the work, which also implies that he earns lesser for that month and might end up not getting an offer. So what is the way to work in the same company and yet earn more?

In conversation with other testers in the company during lunch, the monk heard a couple of testers lament about the development teams not fixing the bugs found by them. One tester said, "I bet a 100 rupees on each of these bugs" and other testers too started making similar statements. The monk who was listening to this got an idea and asked all these testers, "did you say 100 rupees to convince developers to fix a bug?" and then testers replied, "Oh yes!"

The monk went back to the monastry in search of his Guru to seek help to win the bet that was placed on each bug. The Guru had left for a world tour but had left a note to all the monks who came in search of him and the note said, "Your problems will be solved even if I am not here to help you and the one who can help you this time is yourself". After reading this the monk didn't get disappointed but thanked his Guru for leaving such a wonderful note.

The monk boarded a bus to head back to office and at the bus he handed over a 10 rupee note to purchase a ticket. The conductor said, "Sorry, I cant give you the ticket, the low battery condition in this ticket generator will make the ticket get stuck during the print out and its a very painful job to remove the paper out and fix the roll in the position and hence we are losing money and business because of this" and the monk said, "Thank you! I got the answer for a question that was bothering me".

The monk, on reaching office called for a meet with other testers and asked them to bring their bug report print outs. Everyone gave their bunch of reports and the monk started his homework.

He picked a bug that was logged with a low battery operation of an embedded product where the developers had commented "Users are not supposed to use the product in low battery". The monk went to the developer and narrated the incident that happened in bus and also added that, "I guess the government is planning to sue the company that provided that machine. As ours is a huge company where different products are developed, are you sure its not our company thats going to be sued?"

That question to a developer was enough for the monk to make his first 100 rupees. As days passed, the monk narrated a lot of real time stories to developers who had offered reluctance to fixing a lot of bugs assigned to them and the monk made a lot of money. As the stories from the monk became popular among the developers in the company, developers loved listening to monk' stories and the monk had a very high credibility among all teams.

The testers conducted a meet and discussed about the monk who made a lot of money through them and decided to cancel their bets thereafter and some testers said, "Ah! I can say better stories, what big deal? Let me convince the developers hereafter and I am not going to pay that already rich monk anymore"

The monk had not only caused a revolution within himself, he had also created an evolution, the way other testers wanted to work.

The monk decided to go to a new place looking for more and different kind of problems. He made a lot of money solving such problems and eventually became one of the richest tester of the world!

Lessons to learn from the story of a monk who sold bugs:

• Everyone needs something convincing to take up a task, be it fixing a bug or executing scripts.
• Developers need some real time scenarios, facts, customer information and information about customers knowledge, models in which the customer uses a product in a packaged form - story - to get convinced to fix bugs.
• One who constantly thinks of solving a problem, will find the solution anywhere.
• The most reliable person for help, is yourself.
• Testers need to develop and practice a skill of story telling to get better at selling bugs.
• Testing is not an activity of improving quality, its an activity of finding information and it is the product/development teams who fix those issues for improving the quality. In case you still want to think that testing is an activity of improving the quality, you might want to become a best bug seller to continue thinking of it.
• Testing is not necessarily a computer science subject and its life science, social science, ... all science and all non science, too.
• There is a traditional way of making money and as a tester if you take the traditional way, you make less with it.
• Some bugs are born with self explanatory story but some aren't and testers need to build them.
• More your sales figure ( selling bugs, I mean) higher is your credibility and as testers if you don't have credibility, you might not be able to boost your sales figures further.
• Pradeep Soundararajan will keep writing such stories without fearing the people who try putting their name as authors and exposing themselves as idiots, fool.

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

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?
No

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

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!

pradeep:

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.

Simple!

( 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

Curiosity (,s)kills (and) bad testers

Jon Bach ( brother of James Bach ) said, "It's easy to teach technology than to make the students curious" addressing students of a reputed university in United States.

I addressed Masters and PhD students who made into India's premier institute - Indian Institute of Technology, Mumbai because they were more curious than others who prepared for the entrance examinations. The people to whom I spoke were also a part of incubatee company Feast Software in IIT, Mumbai. While returning to Bangalore from Mumbai, I had to spend a night in the airport waiting for the early morning flight.

Michael Bolton, had gifted me a Moleskine Note Book during our first meet and in fact Moleskine notes is something that pulled me and Michael together, more close, even before we had met.

I use the Moleskine Notes - to take notes while I test, to use my time wisely in writing something that can help me do a better testing, to capture all learning that nature has bestowed, to note down points, rants, musings, tips and tricks from testers and testing business guru's I meet.

I offered an Indian version of Moleskine to my student Sathish Kumar, who is a top blogger on testing in Cognizant Technology Solutions internal blogs.

The Moleskine notes had a busy time at airport while I kept thinking and writing a lot of stuff. One such topic that I thought, wondered and wrote is:

What has made me curious about things I hear, I see, I touch and things that I want to see, I want to hear and want to touch?

1. In my childhood, my parents couldn't afford to get me things I wanted and it made me curious to know more about those things when I saw others using it or the ad's associated with it flashed on Television.
2. I was forced to feel ashamed of not knowing certain things by my primary and high school teachers. I could have learned it as the information passed me.
3. Some men appeared to be happy of knowing certain things. I wondered what kind of happiness do such men get when they gain the knowledge on something that interested them.
4. Some people ate a food that appeared to be attractive to my tongue and brains, which I could not afford.
5. A friend of mine claimed to enjoy something ( a toy, an experience at a theme park, a game that he played, a place to which he had been) which I could not because I could not afford it or I was not willing to go for it.
6. Every time when I look back at my own actions, behavior, decisions, foolish stuff that I did... I wonder "why did I do that?".
7. I couldn't be in all professions and hence learning from people in other professions interested me.
8. I was a kid 2 decades ago. ( virtue of being curious )
9. Sometimes I didn't have anything to do and became curious about 'what happens next?'.
10. Knowing people, like Sir Thomas Alva Edison, my father - Soundararajan Govinda Rao, James Bach, Jerry Weinberg, Michael Bolton, Sridhar Krishnamurthy, Ravi Joshi, Sudhindra Haldodedri inspired me to think, "how could I become one such?"
11. I was fooled, several times.
12. I was christened "dumbo" in my teenage by my friends and high school teachers.
    
13. My happiness was directly proportional to the things I knew.
14. I enjoyed breaking rules. ( at home, school and at work - when I am testing )
    
15. I always wanted to be the best (but didn't believe in getting 1st rank in school and college as the way to achieve it)
16. I enjoyed failures and started enjoying more of it when people wondered and asked me "what makes you smile when you fail?"
    
17. Since childhood, I was in love with questions.
18. I enjoyed others curiosity.
    
19. My father made me wait for over 20 years to appreciate any work that I did. ( although I could sense that he felt happy every time I shared a little achievement ). I was curious to get it out from him and the only way is to do something great that he volunteers an appreciation. I wasn't aware of what he might consider as a great work.
    
20. My uncle N. Radhakrishnan, with whom I spent most of my childhood, kept inspiring me with the ways he solved problems that appeared in front of him. Today I realize, where I started off to learn "lateral thinking" .
    
21. James Bach and Michael Bolton tested me against their exercises.
    
22. I am curious to know what points I might have missed while listing this for you.

I doubt if you can show me a great tester who isn't curious about things but I can take a bet - "show me a bad tester, I shall help you discover a lack of curiosity in him". [ he might be curious on something else that doesn't help in testing]

Curiosity makes people to ask questions. Those who question, have more chances to become a better tester or be great problems solvers in the professions they chose.

Ben Simo, a senior tester from United States is one among the most curious people I have recently come across. You could see him write, think and comment on different and wide variety of topics in testing.

"If you are curious, you attract other curious people and hence both of your curiosity grows further". Ben and I have been attracted towards each other's work, blogs, ideas and thought process. Aren't you curious to know more about Ben Simo?

Curiosity helps in curing all diseases that stop you in becoming a good tester. Be curious, get cured!

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

Tester Tested interviews Braidy Tester

Braidy Tester has been interviewing great testers for Dr Dobb's Journal. I think I should say, I was just lucky to have been interviewed by a great tester like Michael Hunter.

Michael Hunter blog is widely read in India too. In fact, it is one of my friend who told me that my interview has appeared in Michael's DDJ blog and I blogged about it: Braidy Tester interviews Tester Tested .

You might want to check http://thebraidytester.com to know more about him, his bio, his articles and presentations.

Michael Hunter is an Expert Tester and Test Architect for top secret projects of Microsoft. Lucky Microsoft!

I thought why not I interview the interviewer - [ Hunter hunted :) ] So, here it goes...

PS: What does "Braidy Tester" mean to you?

MH: “The Braidy Tester” is my personal brand. I often braid my beard (as you can see on my MSDN blog [http://blogs.msdn.com/micahel]). When I was preparing to start that blog I spent some time contemplating what to call it. I wanted something snazzier than “One More Microsoft Tester Blogger”. Eventually I decided that weren't that many testers who braid their beards, so I settled on "The Braidy Tester".

PS: How has your experience of interviewing great testers been, so far?

MH:It is a lot of fun! I enjoy hearing other people's views on testing. I especially enjoy hearing about their favorite bugs!

PS: If you chose to answer one question from your own interview, what would that be? and what would be it's answer?

MH: I'll pick "What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?" I think the most important thing for a tester - or a developer - or anyone - to know is that they will never know everything and so there will always be something more for them to learn. The most important thing for them to do is to go learn it! Learn about testing, development, design, art, music, geography, calculus, how people learn, whatever. I find that everything I learn about has something to teach me about testing.

PS: How do you test the code you write? ( after all the great testing experience)

MH: I am a big fan of unit tests and Test Driven Design. I am way more confident in my code when I have TDD'd unit tests backing it up! I also think about testing while I am developing - what tests will be interesting (and will my code survive them), how can I make my code more testable. I look at my code through white box, grey box, and black box glasses. I run through the checklists and mnemonics I've developed and acquired. Then I give my code to other testers and learn what I missed!

PS: There is a lot of confusion over terminologies and definitions in testing, in my opinion. If you feel the same, how do you handle the confusion when you speak or communicate with a tester whose definitions and terminologies appear to be different from yours?

MH: This can definitely block productive conversations. The first - and often the most difficult - step is to realize a conflict in definitions exists. Once you are aware of that you can make the conflict explicit: "It seems to me we don't all mean the same thing when we say 'dogfoodable'." Then you can proceed to form a common definition.

PS: What thoughts run through your mind when you find a bug in a product you bought.

MH: First I say "Hey look! A bug!" And show it off if it's cool enough. Then I wonder how the company missed it. Then I ask "What would have to be true in order for this company to ship this bug?" That last question is the most interesting I think.

PS: What has been the heights of you enjoying testing?

MH: I enjoy finding bugs. Especially the ones which take time and skill and effort to track down. Showing bugs to developers is fun too. My biggest thrills, however, come when I help prevent bugs from occurring in the first place!

PS: There is always something to learn from everyone and everything around for testers. Do you have an experience that you learned something from a kid?

MH: I find watching children interesting because they are so inquisitive. The younger they are the fewer assumptions they seem to make. When I talk about testing I suggest learning to think like a two-year-old: develop the ability youngsters have to come up with an endless stream of questions about everything. Poke at everything in many different ways and you will almost certainly find a case your developer didn't expect!

PS: Tell us about a ( or a set of ) question that you have been asking yourself and how you found answers to them?

MH: When someone else finds a bug in my area I ask why I missed it. When someone finds a bug in my code I ask what I can do to not make that mistake again. A lot of what I am looking at right now is how I interact with other people. Why did I react so angrily to that person? Why am I happy to help this person and not this other one? The more I understand about how and why I interact with people the way I do, the more I can change my interactions to be more effective.