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
Tuesday, August 28, 2007
Thursday, August 23, 2007
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
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
Friday, August 17, 2007
Apology to my dearmost readers
I apologize to all my dear readers who shocked me with their comments when I announced that I wont be writing further in this blog because (some) Indian testers were plagiarizing (claiming themselves as authors and not owing credits to the author [ me] ) my posts and articles.
Each comment that I received played an important role in reconsidering my decision. Kindly excuse me for that. I am ashamed of my behavior and I understand that things are beyond my intuition because this is not my blog anymore but your blog and your blog will always be active as long as I am alive and I shall be alive for a long time because...
James Bach said, "You can't be killed, your destiny is to help testers"
Yours,
-- Pradeep Soundararajan
Each comment that I received played an important role in reconsidering my decision. Kindly excuse me for that. I am ashamed of my behavior and I understand that things are beyond my intuition because this is not my blog anymore but your blog and your blog will always be active as long as I am alive and I shall be alive for a long time because...
James Bach said, "You can't be killed, your destiny is to help testers"
Yours,
-- Pradeep Soundararajan
Wednesday, August 08, 2007
How does Testing look from the eyes of Tester Tested?
Michael Bolton, gave me a writing exercise a month back ( to rewrite an article that I wrote without changing the meaning but changing the examples ) when I showed him a piece of my work that was published by Mahantesh Ashok Pattan, a fundoo test professional from Microsoft. Mahantesh currently heads a testing excellence team in Microsoft's Hyderabad campus. Mahantesh honored me when he asked if I could write an article for his upcoming software testing website. So here goes my exercise result ...
How does Testing look from the eyes of Tester Tested? Version 2.0
Testing - from my eyes looks different, each day. Everyday, I ensure that I learn something new, observe something more carefully, listen to something more carefully, think deep on a topic that I choose to think, ask questions, read what others write about testing, teach testing to someone, learn a skill from someone, test, self critique my own testing, use Wikipedia/Google, practice the skills that I have developed yesterday, day before yesterday and what you might call as “past” and think about the future.
That doesn’t mean I am a workaholic! How can that be?
3 years back, I went to meet a friend in Jayanagar 4th block, Bangalore. While we we were having a walk the talk session, I noticed 2 child rag pickers running towards a food packet that was lying in a dust bin. A dog was running from the opposite direction, trying to grab the food packet before the 2 rag pickers could get it. The dog lost battle and the 2 rag pickers put their hands into the food packet. I was shocked witnessing this scene (without knowing that a bigger shock was waiting for me)
Today I can say, "The two rag pickers taught me a wonderful lesson that I can apply to testing, to better my testing"
Here is what happened: While the two rag pickers put their hands on the food packet, I shouted, "Drop that, I shall get you good food in a hotel" and their body language suggested to me that they would come with me to the hotel.
I started walking towards a hotel nearby to get them good hot food. Minutes before we reached the hotel, I turned back to see if the 2 guys are following and I noticed that one guy still held the food that he could hold picked from the food packet while the dog had a thankful look at me as the guys had dropped the food packet.
I turned to him and said, "Hey, I told I would get you good food but why aren't you throwing that junk food?"
He replied, "Well, what if the hotel is closed? what if you change your mind? what if you played a prank on us? I still have something to eat as compared to the other guy who doesn't have anything."
Poverty might have made him say that but I was shocked by his thinking capabilities. I am sure he has not had any formal education and everything that he learned is through his experiences in life and is also having the same challenge that we face, "survival of the fittest".
When this incident happened, I must admit that I didn't think of a testing lesson that I could learn from it but an year later when I sat relaxed in my chair after a good heavy meal and I thought about the rag picker incident, something that is related to testing struck me.
We testers lose control of things many times that might have been of great help to do a better testing. For instance, I have worked with testers who waited for the requirement documents to arrive although the product ( in some shape ) was in hand.
The boy who had a little food in his hand still had control of the situation and thought of possible situations in which he might have lost everything ( the food packet and the good hot food that I promised ) had he not done that act. Taking control of the situations ( no matter how hard it is ) is a skill that testers need to conciously practice.
An oracle ( not the database ) is a principle or mechanism in which we identify problems. If you learn and start using oracles consciously, I guess you might be in a position to take control of a situation which demands you to test without specifications or with less or poorly documented specifications.
Case 1: I hand over you my mobile phone and ask you to send an SMS and you see the application crashing for that operation; would you call it a bug/issue? (Although you don’t know what the requirement document for the mobile phone that I possess say)
Case 2: I hand over my mobile phone to you and ask you to open each application and exit it. In all applications you use the Right Soft Key to exit whereas one application demands you to exit using the Left Soft Key. Would you have something to say or ask?
In Case 1 and 2, we are using “oracles” of consistency and heuristics (fallible method of solving a problem) to find or discuss about an issue. Doesn’t that mean having diversified set of oracles, heuristics, and test design techniques can fetch great value for the testing you do?
We have a control over the software, platforms, our thoughts, ideas, questions we can ask, skills that we can put to practice or use when such a demanding situation arises, knowledge that we can bring in, use different heuristics and oracles and try reaching closer to the solution than to stay far away by saying, “Where is the spec, I can’t test without it”. You might want to make a note or mention a risk that a specific document that wasn’t available to you could have helped you go more close to what others might call as “great testing”.
Thats how I learned an important lesson from a rag picker!
Now, you could observe that I was actually supposed to have fun while being with my friend and not think about testing. I did have fun and at the same time I was conscious to see if I have missed an important learning that helped me better my testing. I usually don’t miss the fun nor the learning and hence I hardly get tired.
Here is another story, which I shall connect to the above one, in an interesting way.
A tester reporting to me introduced me to her husband by saying, “This is Pradeep, a passionate tester.” I love to be introduced that way since I am aware that I am one such.
Her husband immediately shot a question: “My friends who are into testing say that bringing testing to their life has caused some serious damages to their relationships, how has it been with you?”
Read my reply to that question, as careful as possible: “Thanks for asking me this question. I am probably one of the most passionate testers and I am sure that those who really know, what testing is, wouldn’t mess up his/her life with it. It appears to me that your friends who claim to know testing, don’t know that because had they known, they wouldn’t have got it into their personal lives”
I have enjoyed some great relationships with people. If you claim to be a good tester, it means testing has taught you not to get testing into relationships although testing happens between relationships and lives in a sub conscious level.
“Testing is questioning a product in order to evaluate it” – James Bach
Now the time for connecting two stories: The first story says, “There is always a thread about testing that I run in my mind while or after having fun or watching TV or chatting with friends” and the second story says, “If you really know what testing means, you wouldn’t bring it into your personal life”.
Connecting both of them I want to mean, I try to look for opportunities to learn from things that are happening around that I can apply for my testing activity for which I am paid and *not* to use testing as an approach to build/spoil relationships or systems that others are wanting to use after my usage. For instance, after withdrawing cash from an ATM, I do not intend to perform some quick tests, because it might stop the system and someone in emergency might have to go looking for another ATM.
You have been seeing testing from my eyes, time for you to see it from your own eyes, and I hope you see it in a better way than mine, teach me something and help me to see something different from your eyes. E-mail me at pradeep.srajan@gmail.com
---
If you have liked this article, you might want to read a different version of the same and here is the link. If you haven't liked this article, maybe you want to read it again :)
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 does Testing look from the eyes of Tester Tested? Version 2.0
Testing - from my eyes looks different, each day. Everyday, I ensure that I learn something new, observe something more carefully, listen to something more carefully, think deep on a topic that I choose to think, ask questions, read what others write about testing, teach testing to someone, learn a skill from someone, test, self critique my own testing, use Wikipedia/Google, practice the skills that I have developed yesterday, day before yesterday and what you might call as “past” and think about the future.
That doesn’t mean I am a workaholic! How can that be?
3 years back, I went to meet a friend in Jayanagar 4th block, Bangalore. While we we were having a walk the talk session, I noticed 2 child rag pickers running towards a food packet that was lying in a dust bin. A dog was running from the opposite direction, trying to grab the food packet before the 2 rag pickers could get it. The dog lost battle and the 2 rag pickers put their hands into the food packet. I was shocked witnessing this scene (without knowing that a bigger shock was waiting for me)
Today I can say, "The two rag pickers taught me a wonderful lesson that I can apply to testing, to better my testing"
Here is what happened: While the two rag pickers put their hands on the food packet, I shouted, "Drop that, I shall get you good food in a hotel" and their body language suggested to me that they would come with me to the hotel.
I started walking towards a hotel nearby to get them good hot food. Minutes before we reached the hotel, I turned back to see if the 2 guys are following and I noticed that one guy still held the food that he could hold picked from the food packet while the dog had a thankful look at me as the guys had dropped the food packet.
I turned to him and said, "Hey, I told I would get you good food but why aren't you throwing that junk food?"
He replied, "Well, what if the hotel is closed? what if you change your mind? what if you played a prank on us? I still have something to eat as compared to the other guy who doesn't have anything."
Poverty might have made him say that but I was shocked by his thinking capabilities. I am sure he has not had any formal education and everything that he learned is through his experiences in life and is also having the same challenge that we face, "survival of the fittest".
When this incident happened, I must admit that I didn't think of a testing lesson that I could learn from it but an year later when I sat relaxed in my chair after a good heavy meal and I thought about the rag picker incident, something that is related to testing struck me.
We testers lose control of things many times that might have been of great help to do a better testing. For instance, I have worked with testers who waited for the requirement documents to arrive although the product ( in some shape ) was in hand.
The boy who had a little food in his hand still had control of the situation and thought of possible situations in which he might have lost everything ( the food packet and the good hot food that I promised ) had he not done that act. Taking control of the situations ( no matter how hard it is ) is a skill that testers need to conciously practice.
An oracle ( not the database ) is a principle or mechanism in which we identify problems. If you learn and start using oracles consciously, I guess you might be in a position to take control of a situation which demands you to test without specifications or with less or poorly documented specifications.
Case 1: I hand over you my mobile phone and ask you to send an SMS and you see the application crashing for that operation; would you call it a bug/issue? (Although you don’t know what the requirement document for the mobile phone that I possess say)
Case 2: I hand over my mobile phone to you and ask you to open each application and exit it. In all applications you use the Right Soft Key to exit whereas one application demands you to exit using the Left Soft Key. Would you have something to say or ask?
In Case 1 and 2, we are using “oracles” of consistency and heuristics (fallible method of solving a problem) to find or discuss about an issue. Doesn’t that mean having diversified set of oracles, heuristics, and test design techniques can fetch great value for the testing you do?
We have a control over the software, platforms, our thoughts, ideas, questions we can ask, skills that we can put to practice or use when such a demanding situation arises, knowledge that we can bring in, use different heuristics and oracles and try reaching closer to the solution than to stay far away by saying, “Where is the spec, I can’t test without it”. You might want to make a note or mention a risk that a specific document that wasn’t available to you could have helped you go more close to what others might call as “great testing”.
Thats how I learned an important lesson from a rag picker!
Now, you could observe that I was actually supposed to have fun while being with my friend and not think about testing. I did have fun and at the same time I was conscious to see if I have missed an important learning that helped me better my testing. I usually don’t miss the fun nor the learning and hence I hardly get tired.
Here is another story, which I shall connect to the above one, in an interesting way.
A tester reporting to me introduced me to her husband by saying, “This is Pradeep, a passionate tester.” I love to be introduced that way since I am aware that I am one such.
Her husband immediately shot a question: “My friends who are into testing say that bringing testing to their life has caused some serious damages to their relationships, how has it been with you?”
Read my reply to that question, as careful as possible: “Thanks for asking me this question. I am probably one of the most passionate testers and I am sure that those who really know, what testing is, wouldn’t mess up his/her life with it. It appears to me that your friends who claim to know testing, don’t know that because had they known, they wouldn’t have got it into their personal lives”
I have enjoyed some great relationships with people. If you claim to be a good tester, it means testing has taught you not to get testing into relationships although testing happens between relationships and lives in a sub conscious level.
“Testing is questioning a product in order to evaluate it” – James Bach
Now the time for connecting two stories: The first story says, “There is always a thread about testing that I run in my mind while or after having fun or watching TV or chatting with friends” and the second story says, “If you really know what testing means, you wouldn’t bring it into your personal life”.
Connecting both of them I want to mean, I try to look for opportunities to learn from things that are happening around that I can apply for my testing activity for which I am paid and *not* to use testing as an approach to build/spoil relationships or systems that others are wanting to use after my usage. For instance, after withdrawing cash from an ATM, I do not intend to perform some quick tests, because it might stop the system and someone in emergency might have to go looking for another ATM.
You have been seeing testing from my eyes, time for you to see it from your own eyes, and I hope you see it in a better way than mine, teach me something and help me to see something different from your eyes. E-mail me at pradeep.srajan@gmail.com
---
If you have liked this article, you might want to read a different version of the same and here is the link. If you haven't liked this article, maybe you want to read it again :)
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
Thursday, August 02, 2007
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:
-- 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
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
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?
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.
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
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.
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:
Why is testing monotonous? The unspoken truth!
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
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
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
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 :)
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.
Why is testing monotonous? The unspoken truth!
- It's made so by testers who *might* not be able to think or be creative.
- It's made so by testers who *might* be lazy to run those tests.
- 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.
- It's made so by testers who *might* lack passion to test.
- It's made so by testers who *might* want to jump to development and needed a reason that others could accept.
- It's made so by testers who *might* not want to try any new test other than the script that they have been given.
- It's made so by testers who *might* want a reason to jump to another job.
- It's made so by testers who *might* lack motivation to test.
- It's made so by people who *might* be claiming themselves as testers but aren't.
- It's made so by testers who *might* not have skills to find bugs.
- 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?
- 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.
- 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.
- It's made so by testers who *might* want to do exploratory testing but are stuck in scripted approach.
- It's made so by testers who *might* be doing tasks with same mistakes.
- 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)
- It's not testing that is monotonous, it's testers thinking that is monotonous.
- It's made by testers who monotonously say "testing is monotonous"!
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
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
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
Monday, June 25, 2007
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?
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
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?
- 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.
- 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.
- 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.
- Some people ate a food that appeared to be attractive to my tongue and brains, which I could not afford.
- 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.
- Every time when I look back at my own actions, behavior, decisions, foolish stuff that I did... I wonder "why did I do that?".
- I couldn't be in all professions and hence learning from people in other professions interested me.
- I was a kid 2 decades ago. ( virtue of being curious )
- Sometimes I didn't have anything to do and became curious about 'what happens next?'.
- 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?"
- I was fooled, several times.
- I was christened "dumbo" in my teenage by my friends and high school teachers.
- My happiness was directly proportional to the things I knew.
- I enjoyed breaking rules. ( at home, school and at work - when I am testing )
- 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)
- I enjoyed failures and started enjoying more of it when people wondered and asked me "what makes you smile when you fail?"
- Since childhood, I was in love with questions.
- I enjoyed others curiosity.
- 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.
- 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" .
- James Bach and Michael Bolton tested me against their exercises.
- I am curious to know what points I might have missed while listing this for you.
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
Subscribe to:
Posts (Atom)