Sunday, February 22, 2009
Monday, January 26, 2009
Learning to test better by teaching testing
Make a list of some of the teaching staff that considered bad at school or college. You might be able to notice a pattern - most of them were not willing to learn while they were teaching. Here are some of my stories and attempts that I made during my experience as a coach in software testing.
Story 1
I was teaching at Datamatics 2 weeks before. When it was time to officially end the workshop, a participant asked me, "What did you learn in these 2 days of workshop?". I was so happy to have got that question. I thanked her for the question and listed some of the learning I had in those 2 days.
Story 2
Lunch tables are a great learning ground. At Datamatics, I was joined by a group of testers at the lunch table. I ordered for a Dal Kichdi that some other people had ordered too. As I ordered late, others had started off with what they were served. When I got my Dal Kichdi and rowed the spoon over it for grabbing the first bite, I saw a hair (hopefully human one) in it and then found more. I picked a hair and showed it to testers and asked, "Did we order for this?" (meaning, no one order for bugs to be served with the software they buy) and then the brilliant Saurabh Sahoo, Test Lead at Datamatics asked, "Do you know why you found the hair while we didn't?", and the curious me said, "Can you explain, please?" for which he said, "You were looking at the plate while we were so much engrossed in the discussion and were watching each other's face".
That's a nice observation. It helped me explain to the people over table - that's what happens when you run scripts or test cases that have an expected result, "You are too much focused looking at the expected result that makes you blind to see other things happening in the environment. Having multiple oracles in your mind helps you see more than just the expected result and hence you'd be able to spot more problems than what you have been doing".
I also added to it and said, "I wish we could say to our customers, why are you looking at the screen?" when they say they found a bug with our software.
I think that at least made Saurabh Sahoo convince that its worth spending time to learn things that I was trying to teach (and learn) and he spend an additional two and half hours after the workshop with me and he is determined to do a much better job. I learned a great deal answering the questions he asked me on clearing traps.
Answering questions like that definitely helps me in negotiating with management and clients.
Story 3
I was teaching at a Fortune 100 organization in Pune a couple of months ago. Within just 20 minutes of starting my workshop, the Test Lead announces to the whole class "This is class is a waste of time. Lets go back to work".
What if you are in front of your customer and your customer wants to walk out of a meeting because they didn't like your idea? You might not be able to afford to lose all customers especially if recession is around.
I made an announcement, "All of you have the freedom to walk out of the class but I'd be happy if you answer a question: Have you ever walked out of a movie just because the titles of the movie suck?
If your answer is No, why would you want to do it here?"
Plus
I did something that I learned from the book Turning Numbers Into Knowledge that again cites Bruce Lee's master.
I took a tea cup and poured water into it and kept pouring despite the cup overflowing and quoted Bruxe Lee's master, "Either your cup is too small or it is already full of opinions".
The result: I am teaching in the same organization again next month. The legs that rose up to walk out sat back and enjoyed the ride. Some even wrote to their management to have the class for other testers in their group.
Story 4
A common problem that most testers talk about - is being caught for missing a bug when a customer finds it. A tester in one of the previous workshop said, "It is my responsibility if I miss a bug and hence I have to be more careful with the tests I do". I was reminded of what Michael Bolton said, "I am a character in the story of how a bug got missed". It indicates that, we testers are a part of the entire story and we do not play the hero role in a bug that missed our hands.
That tester was adamant that testers should be made completely responsible for it and not anyone else because it was their fault and they shouldn't have missed it. I tried asking him, "How about making the person who put the bug into the product more responsible for it than you?" and yet that didn't help.
I made a pretty bold move, "I am going to slap you now. Would you blame yourself for standing in a place where I was swinging my hands or blame me for doing something I shoudn't have done?"
That tester remained adamant but other testers got the message that a tester is a character in the story of how a bug got missed and not the hero in the same story. Later that night when I was self retrospecting, I realized that I should have used a non violent example to explain it. Teaching testing to experienced testers helps in correcting your communication and thinking aspects.
Some important points to consider
Story 1
I was teaching at Datamatics 2 weeks before. When it was time to officially end the workshop, a participant asked me, "What did you learn in these 2 days of workshop?". I was so happy to have got that question. I thanked her for the question and listed some of the learning I had in those 2 days.
I also mentioned to them that I make a note of the learning I have in one or the other way. I also mentioned that my blog acts as my note taking tool at times. As you might have seen my Progress Report, the list of events and experiences that I had in every year is well documented.
The question, "What did you learn by teaching me?" is a powerful question to ask someone who is claiming to teach you because if the person has nothing then you know you might not want to sit in that class anymore or being in that class is a waste of your time.
The question, "What did you learn by teaching me?" is a powerful question to ask someone who is claiming to teach you because if the person has nothing then you know you might not want to sit in that class anymore or being in that class is a waste of your time.
In some places I have an answer, "I learned that you can't be taught at least by me" and thankfully those people don't ask me that question. Learning and teaching needs an open mind. I think I must have a close mind to say, "Not everyone have an open mind".
I have learned some great deal of stuff about how to test better by teaching testers how to test. I understand that my brain is not capable of asking all the questions that I'd love to ask myself and hence I need other brains to ask me those questions. Where do I find those brains if I am stuck in one place and I keep interacting with just the same team for over years?
An year and a half back Ben Simo mentioned to me the idea of "Apply inputs that force all the error messages to occur" from James Whittaker's book while we were discussing about error messages. I liked the idea and it then got included in my armory of heuristics to test a product and helps me in model the product in more ways than what I have been doing.
Recently when I was teaching the Hands on Testing Training for Freshers for Edista Testing, Muhammed Kothari, pointed out a tool to me that helped in displaying all error messages programmed in most Windows applications. At every workshop, I ask the participants to challenge me in demonstrating the kind of testing I talk about. At Datamatics the challenge was to demonstrate testing on Microsoft Freecell game. On using the Process Explorer tool, I demonstrated how I could learn how many error messages the product is programmed with and designed my tests to all those error messages ( in other words, all printable strings from the program ). That's one way of demonstrating coverage.
I have learned some great deal of stuff about how to test better by teaching testers how to test. I understand that my brain is not capable of asking all the questions that I'd love to ask myself and hence I need other brains to ask me those questions. Where do I find those brains if I am stuck in one place and I keep interacting with just the same team for over years?
An year and a half back Ben Simo mentioned to me the idea of "Apply inputs that force all the error messages to occur" from James Whittaker's book while we were discussing about error messages. I liked the idea and it then got included in my armory of heuristics to test a product and helps me in model the product in more ways than what I have been doing.
Recently when I was teaching the Hands on Testing Training for Freshers for Edista Testing, Muhammed Kothari, pointed out a tool to me that helped in displaying all error messages programmed in most Windows applications. At every workshop, I ask the participants to challenge me in demonstrating the kind of testing I talk about. At Datamatics the challenge was to demonstrate testing on Microsoft Freecell game. On using the Process Explorer tool, I demonstrated how I could learn how many error messages the product is programmed with and designed my tests to all those error messages ( in other words, all printable strings from the program ). That's one way of demonstrating coverage.
Some curious testers were excited about it and came up and said, "I'd like to use the tool. It helps me find out areas that I might have been missing while testing the product" -- which is cool. [ some? well, one. :-) ]
That's just one of the many ways in which Process Explorer can be of great help to a tester. Note that Process Explorer is a tool. A tool that a tester can use to augment his testing effort and do a better testing. Tools are not just QTP, Winrunner, Loadrunner, Silk, Cotton, Wool etc...
Story 2
Lunch tables are a great learning ground. At Datamatics, I was joined by a group of testers at the lunch table. I ordered for a Dal Kichdi that some other people had ordered too. As I ordered late, others had started off with what they were served. When I got my Dal Kichdi and rowed the spoon over it for grabbing the first bite, I saw a hair (hopefully human one) in it and then found more. I picked a hair and showed it to testers and asked, "Did we order for this?" (meaning, no one order for bugs to be served with the software they buy) and then the brilliant Saurabh Sahoo, Test Lead at Datamatics asked, "Do you know why you found the hair while we didn't?", and the curious me said, "Can you explain, please?" for which he said, "You were looking at the plate while we were so much engrossed in the discussion and were watching each other's face".
That's a nice observation. It helped me explain to the people over table - that's what happens when you run scripts or test cases that have an expected result, "You are too much focused looking at the expected result that makes you blind to see other things happening in the environment. Having multiple oracles in your mind helps you see more than just the expected result and hence you'd be able to spot more problems than what you have been doing".
I also added to it and said, "I wish we could say to our customers, why are you looking at the screen?" when they say they found a bug with our software.
I think that at least made Saurabh Sahoo convince that its worth spending time to learn things that I was trying to teach (and learn) and he spend an additional two and half hours after the workshop with me and he is determined to do a much better job. I learned a great deal answering the questions he asked me on clearing traps.
Answering questions like that definitely helps me in negotiating with management and clients.
Story 3
I was teaching at a Fortune 100 organization in Pune a couple of months ago. Within just 20 minutes of starting my workshop, the Test Lead announces to the whole class "This is class is a waste of time. Lets go back to work".
- How do you deal with such a situation?
- How do you teach someone who doesn't want to learn from you?
- How do you put them in a receptive mode?
- How do you know what to speak to them?
- How do you know if its worth speaking to them anymore?
- How do you know if they are more right than you?
What if you are in front of your customer and your customer wants to walk out of a meeting because they didn't like your idea? You might not be able to afford to lose all customers especially if recession is around.
I made an announcement, "All of you have the freedom to walk out of the class but I'd be happy if you answer a question: Have you ever walked out of a movie just because the titles of the movie suck?
If your answer is No, why would you want to do it here?"
Plus
I did something that I learned from the book Turning Numbers Into Knowledge that again cites Bruce Lee's master.
I took a tea cup and poured water into it and kept pouring despite the cup overflowing and quoted Bruxe Lee's master, "Either your cup is too small or it is already full of opinions".
The result: I am teaching in the same organization again next month. The legs that rose up to walk out sat back and enjoyed the ride. Some even wrote to their management to have the class for other testers in their group.
Story 4
A common problem that most testers talk about - is being caught for missing a bug when a customer finds it. A tester in one of the previous workshop said, "It is my responsibility if I miss a bug and hence I have to be more careful with the tests I do". I was reminded of what Michael Bolton said, "I am a character in the story of how a bug got missed". It indicates that, we testers are a part of the entire story and we do not play the hero role in a bug that missed our hands.
That tester was adamant that testers should be made completely responsible for it and not anyone else because it was their fault and they shouldn't have missed it. I tried asking him, "How about making the person who put the bug into the product more responsible for it than you?" and yet that didn't help.
I made a pretty bold move, "I am going to slap you now. Would you blame yourself for standing in a place where I was swinging my hands or blame me for doing something I shoudn't have done?"
That tester remained adamant but other testers got the message that a tester is a character in the story of how a bug got missed and not the hero in the same story. Later that night when I was self retrospecting, I realized that I should have used a non violent example to explain it. Teaching testing to experienced testers helps in correcting your communication and thinking aspects.
Some important points to consider
- It is easy to teach dull minds that don't oppose and appear to nod for every idea that you share with them. Teaching bright minds are tough and demanding. They teach you a lot about how to test better and what more I want than that.
- Most people who teach testing in India at several training centers haven't done testing at all or haven't done enough testing. So, those who have remained a hands on tester and teaches testing gains a competitive edge.
- If you have that competitive edge then there is good money as well.
- Helps in meeting a lot of different kinds of testers and understanding different contexts, problems and different solutions to problems. It helps in avoiding traps much better and faster and translates to better testing.
- It is a challenge to get to know more about ourselves, get tested , refine communication, thinking, learning, teaching and testing skills.
- Make a list of some of the great testers you know ( in my case Jerry, Cem, Ben, James, Michael, Scott, Kohl, Elizabeth, Vipul ... ), you'd find that they teach extensively. Oh, you have been doing that as well but probably you have been teaching yourself all this time. Think about why do they do that?
- Go, at least teach yourselves.
- Teaching, teaches the teacher about teaching
Monday, January 19, 2009
Progress Report 2008 :: Pradeep Soundararajan
Click on the image below to download the full verison.

Alternatively, you may right click on this link and save the file to your desktop.
Alternatively, you may right click on this link and save the file to your desktop.
Labels
announcement,
bad testing,
inspiration,
learning,
other publications,
pdf's,
people,
process,
progress report,
rapid software testing,
test consulting,
tester,
training,
travel,
videos,
workshop
Thursday, December 04, 2008
Hands on software testing training - Change we need!
All workshops that I conduct has lots of elements of hands on testing and thinking exercises. I myself benefited a lot from hands on testing training approach that James and Michael do in their Rapid Software Testing class.
Over the last few months, I have been working on models of hands on training on software testing for freshers and people who are interested to be good enough to start testing computer software and for organizations who have a tough time getting people to test with lesser supervision than the current magnitude.
I have always been worried about the value of showing thousands of slides on software testing without actually getting a person to test, especially when a person hasn't had any testing experience.
"An ounce of practice is better than tons of theory" - Swami Sivanada
So, here comes a 30 day course on software testing that is hands on training from Satisfice India in partnership with Edista Testing Institute. Edista would be happy to place the participants of this kind of training to their clients who have been wanting freshers and candidates who can test as their resources.
If you were to make a choice between a A+ certified tester who got certified A+ merely based on answering 100 questions versus someone who has a certificate of successful completion of a hands on testing training, whom would you choose?
If you know of any fresher in India, or, if you want someone to benefit from this training kindly ask them to call Noorie @ +91 96322 22326 or e-mail her at noorie.a@edistatesting.com and ask for the hands on testing training for freshers.
I wish I can take a bet against those certification people to challenge those who attend this kind of hands on training for the same 30 days that the certified people take and ask them to see the value. I think I definitely can when I show you the results in the coming months.
Now, what I have written here might not be so wooing as a commercial ad of a testing training but I believe there is more value for the cost and is more worthy of someone's time if they want themselves to be trained good enough to start testing a software.
Oh! I didn't talk about the cost. This training costs twice as much as my 2 day Exploratory Testing class. Yes, its that affordable! And, there are only 6 more seats to be filled.
The good news is, I interviewed Testing Heads/ Vice President - Testing / Founders / CXO of organizations like - Wipro, Applabs, Patni, HP, Target, National Stock Exchange, Infosys, AIG, Edista Testing, VM Logix, ITKO Lisa, Deloite Consulting... at STC 2008 conference last fortnight and asked them a question about hands on training than mere slide show. You guess what their answer would have been or watch the videos at Test Republic in a couple of days.
One of the change India needs is here!
--
Pradeep Soundararajan :: Software Testing Videos: http://www.viddler.com/explore/testertested
Note: If you are interested to attend a 2 hour session on Exploratory Testing in Chennai on Dec 9th e-mail Noorie
Over the last few months, I have been working on models of hands on training on software testing for freshers and people who are interested to be good enough to start testing computer software and for organizations who have a tough time getting people to test with lesser supervision than the current magnitude.
I have always been worried about the value of showing thousands of slides on software testing without actually getting a person to test, especially when a person hasn't had any testing experience.
"An ounce of practice is better than tons of theory" - Swami Sivanada
So, here comes a 30 day course on software testing that is hands on training from Satisfice India in partnership with Edista Testing Institute. Edista would be happy to place the participants of this kind of training to their clients who have been wanting freshers and candidates who can test as their resources.
If you were to make a choice between a A+ certified tester who got certified A+ merely based on answering 100 questions versus someone who has a certificate of successful completion of a hands on testing training, whom would you choose?
If you know of any fresher in India, or, if you want someone to benefit from this training kindly ask them to call Noorie @ +91 96322 22326 or e-mail her at noorie.a@edistatesting.com and ask for the hands on testing training for freshers.
I wish I can take a bet against those certification people to challenge those who attend this kind of hands on training for the same 30 days that the certified people take and ask them to see the value. I think I definitely can when I show you the results in the coming months.
Now, what I have written here might not be so wooing as a commercial ad of a testing training but I believe there is more value for the cost and is more worthy of someone's time if they want themselves to be trained good enough to start testing a software.
Oh! I didn't talk about the cost. This training costs twice as much as my 2 day Exploratory Testing class. Yes, its that affordable! And, there are only 6 more seats to be filled.
The good news is, I interviewed Testing Heads/ Vice President - Testing / Founders / CXO of organizations like - Wipro, Applabs, Patni, HP, Target, National Stock Exchange, Infosys, AIG, Edista Testing, VM Logix, ITKO Lisa, Deloite Consulting... at STC 2008 conference last fortnight and asked them a question about hands on training than mere slide show. You guess what their answer would have been or watch the videos at Test Republic in a couple of days.
One of the change India needs is here!
--
Pradeep Soundararajan :: Software Testing Videos: http://www.viddler.com/explore/testertested
Note: If you are interested to attend a 2 hour session on Exploratory Testing in Chennai on Dec 9th e-mail Noorie
Tuesday, November 25, 2008
Grammy Award for Michael Bolton and others
Michael Bolton, the singer has won Grammy Awards. This Michael Bolton , a little known mandolin player and largely known singer of good intellectual software testing has been awarded for his innovation and contribution to the community you and me live in, at EuroStar 2008, one of the biggest conferences in the world.
Wait a minute, T H E Y won the award!
I just want to celebrate this more than any of my own success because it makes me so proud that my singing is influenced by THEY. Read more ->
Some Indian testers won thought leadership award at Test 2008 conference. Wondering who they are?
Plus, at STC2008 conference that concluded today, Sharath Byregowda, ( another proud moment for me ) won the Best Contributor award for Test Republic
What does all this say to you?
If you want to be a tester who goes beyond the traditional, great recognition awaits you BUT if you do things just for recognition you won't get it. Come out and communicate if you haven't been communicating or else you will see yourself vanishing.
I am sandwiched between my guru and my student winning the award at around the same time. What a fantastic moment for me. During the toughest of the times, I kept hoping that software testers who focus on human skills should shine in the future and those who aren't willing to challenge their minds should vanish.
This is just the beginning of a greater success of these people. Wake up or Vanish!
Wait a minute, T H E Y won the award!
I just want to celebrate this more than any of my own success because it makes me so proud that my singing is influenced by THEY. Read more ->
Some Indian testers won thought leadership award at Test 2008 conference. Wondering who they are?
Plus, at STC2008 conference that concluded today, Sharath Byregowda, ( another proud moment for me ) won the Best Contributor award for Test Republic
What does all this say to you?
If you want to be a tester who goes beyond the traditional, great recognition awaits you BUT if you do things just for recognition you won't get it. Come out and communicate if you haven't been communicating or else you will see yourself vanishing.
I am sandwiched between my guru and my student winning the award at around the same time. What a fantastic moment for me. During the toughest of the times, I kept hoping that software testers who focus on human skills should shine in the future and those who aren't willing to challenge their minds should vanish.
This is just the beginning of a greater success of these people. Wake up or Vanish!
Labels
announcement,
inspiration,
learning,
people,
skilled testing
Friday, November 07, 2008
Rating testers based on number of bugs they find - It's definitely possible
In a CMM Level 5 organization I worked for about 2 years back, I got an e-mail from my Senior Manager that testers would be rated based on number of bugs they find. At that time I was an ace bug slogger ( means, I logged a lot of bugs ) for the team.
I was the first one to revolt on that idea of rating a tester based on the number of bugs they find despite knowing the fact that it could benefit me a lot. I was aware of the importance of other testers in the team who weren’t as good bug sloggers like me but had some skills that I did not have and were important skills that a test team required. For instance, I wouldn’t execute test cases. A combination of scripted and exploratory testing was important for that team. A customer insisted that the test cases ( about 140 ) were executed and report being sent to him without discarding the idea that we could do exploratory testing. Some testers in the team had brilliant ideas to create test files that helped the team in finding a lot of bugs. Some testers were documentation savvy guys who used to sit hours together patiently to generate release reports. We shared our tasks pretty well.
I replied to the e-mail saying, “Despite I see that this policy could benefit me, I see this as a threat to the value we testers can add and have been adding. I wouldn’t mind to quit the organization if this policy is serious and be put to action”.
The idea of losing a tester like me on a project whose business is a lot of US Dollars sounded bad to the management and they changed the policy to “Testers will be rated based on the number of bugs that customers find” for which, my reply was, “This doesn’t make me any comfortable”.
In this context, I started to look for articles that talk about testers being rated based on number of bugs found by them and bumped into Dr Cem Kaner’s article Don’t Use Bug Counts to Measure Testers and the conclusion is super fantastic “If you really need a simple number to use to rank your testers, use a random number generator. It is fairer than bug counting, it probably creates less political infighting, and it might be more accurate”.
I was very much impressed about the ideas shared there and shared that article with my management. No measurement of bugs to rate testers happened to my knowledge.
Till a couple of days before, I was thinking that testers should not be rated based on number of bugs they find.
Well, its possible.
I read a post from Sharath Byregowda, a tester whom I respect and collaborate with inBangalore . No, he didn’t write that it’s a good idea to rate testers based on number of bugs they find. I often question myself, my ideas and beliefs.
Can I still use bug count to measure testers although I know it’s a bad idea and make a good judgment out of it ?
Then an idea struck, “Measure testers based on their reaction to being rated based on number of bugs they find”
All good and great testers that I know and those who understanding testing better than the major population of testers would oppose the idea. There you are – you know who understands testing better than your other staff and whom to retain and who cannot be easily replaced.
Those who test whatever information they get are likely to test the product better than those who don’t test the information they have been given.
If you give a specification document, test plan document, test case document to someone who doesn’t test the information ( which most management does ) in it, you have a problem with your hiring and staff. I have witnessed testers who think of those documents as Bible, The Holy Quran and Bhagvad Gita.
Watch the following video. While you watch the video answer my question:
Isn’t what you see in the video strikingly similar to what most testers do?
Step 1: Open that
Step 2: Click Here,
Expected Result: This should happen and then you get a peanut.
Many such peanuts satisfy your hunger.
Such humans can definitely be rated on the number of times they find things that they are expected to find through a tightly written script. Now you know why some testers use the term “monkey testing” as something that they do and also now you know why their being paid peanuts.
Disclaimer: The usage of monkey training video isn’t to talk ill about the training that was happening to those monkeys there. I respect and appreciate that those monkeys are being trained for a noble job of helping physically handicapped people get their jobs done. Kudos to the team at http://www.monkeyhelpers.org and for their brilliant idea of using monkeys to help physically handicapped humans.
--
Pradeep Soundararajan - Software Testing Videos: http://www.viddler.com/explore/testertested
I was the first one to revolt on that idea of rating a tester based on the number of bugs they find despite knowing the fact that it could benefit me a lot. I was aware of the importance of other testers in the team who weren’t as good bug sloggers like me but had some skills that I did not have and were important skills that a test team required. For instance, I wouldn’t execute test cases. A combination of scripted and exploratory testing was important for that team. A customer insisted that the test cases ( about 140 ) were executed and report being sent to him without discarding the idea that we could do exploratory testing. Some testers in the team had brilliant ideas to create test files that helped the team in finding a lot of bugs. Some testers were documentation savvy guys who used to sit hours together patiently to generate release reports. We shared our tasks pretty well.
I replied to the e-mail saying, “Despite I see that this policy could benefit me, I see this as a threat to the value we testers can add and have been adding. I wouldn’t mind to quit the organization if this policy is serious and be put to action”.
The idea of losing a tester like me on a project whose business is a lot of US Dollars sounded bad to the management and they changed the policy to “Testers will be rated based on the number of bugs that customers find” for which, my reply was, “This doesn’t make me any comfortable”.
In this context, I started to look for articles that talk about testers being rated based on number of bugs found by them and bumped into Dr Cem Kaner’s article Don’t Use Bug Counts to Measure Testers and the conclusion is super fantastic “If you really need a simple number to use to rank your testers, use a random number generator. It is fairer than bug counting, it probably creates less political infighting, and it might be more accurate”.
I was very much impressed about the ideas shared there and shared that article with my management. No measurement of bugs to rate testers happened to my knowledge.
Till a couple of days before, I was thinking that testers should not be rated based on number of bugs they find.
Well, its possible.
I read a post from Sharath Byregowda, a tester whom I respect and collaborate with in
Can I still use bug count to measure testers although I know it’s a bad idea and make a good judgment out of it ?
Then an idea struck, “Measure testers based on their reaction to being rated based on number of bugs they find”
All good and great testers that I know and those who understanding testing better than the major population of testers would oppose the idea. There you are – you know who understands testing better than your other staff and whom to retain and who cannot be easily replaced.
Those who test whatever information they get are likely to test the product better than those who don’t test the information they have been given.
If you give a specification document, test plan document, test case document to someone who doesn’t test the information ( which most management does ) in it, you have a problem with your hiring and staff. I have witnessed testers who think of those documents as Bible, The Holy Quran and Bhagvad Gita.
Watch the following video. While you watch the video answer my question:
Isn’t what you see in the video strikingly similar to what most testers do?
Step 1: Open that
Step 2: Click Here,
Expected Result: This should happen and then you get a peanut.
Many such peanuts satisfy your hunger.
Such humans can definitely be rated on the number of times they find things that they are expected to find through a tightly written script. Now you know why some testers use the term “monkey testing” as something that they do and also now you know why their being paid peanuts.
Disclaimer: The usage of monkey training video isn’t to talk ill about the training that was happening to those monkeys there. I respect and appreciate that those monkeys are being trained for a noble job of helping physically handicapped people get their jobs done. Kudos to the team at http://www.monkeyhelpers.org and for their brilliant idea of using monkeys to help physically handicapped humans.
--
Pradeep Soundararajan - Software Testing Videos: http://www.viddler.com/explore/testertested
Labels
bad testing,
context,
creative ideas,
job,
learning,
new ideas,
tester
Tuesday, October 28, 2008
Testing the number of years of software testing experience
I am a software testing coach. I am not the kind of software testing coach who runs through hundred of slides about how to drive a car for those aspiring to drive a car or for those who aspire to drive better. I coach by putting each one of them in drivers seat. That's how James Bach and Michael Bolton coach software testers. I believe they picked up such an approach from Jerry Weinberg.
I am young and will remain young. Some people who sit in my class have a problem with my age. Some people who sit in my class have a problem with their age. They see me as young as they were about a decade ago or half a decade ago and wonder what would I be able to teach them.
This makes my job all the more challenging. I try to crack tough nuts even before I get started off with my class. One such thing happened 2 weeks back in Pune while training for a corporate client when a Test Lead attempted to walk out of my class yelling "this is the most useless class I have ever taken".
Well, I just wondered if he ever walked out of a movie just watching the first minute and deciding the whole movie was useless?
Jerry Weinberg said "Words just carry 10% and the rest is music", which is so true.
I infer from the kind of music I heard from him and the number of white hair he had grown, the problem was not with the class but with his age and mine. Do you ever go out and say "Well, you are inexperienced to teach me?" Don't you just show that in the behavior?
That evening I was conversing about the incident with Manoj Nair and was trying to question "The number of years of experience syndrome".
How many days make an year?
365. 25 ( that's three sixty five and a quarter days )
How many hours make a day?
24 hours ( that's twenty four hours )
When you ask someone about their experience, what metric do they use?
X Number of years of experience
Is that true?
When people say I have 10 years of experience:
Are they trying to say, they worked for 365.25 x 10 = 3652.5 days
Are they trying to say, they worked for 3652.5 x 24 = 87660 hours
We all know that Saturdays and Sundays are holidays and we also have a leave/holiday package an employer gives to all its employees.
So, for those who claim 10 years of experience, ignoring Saturdays, Sundays and average leave/holiday package of 30 days per year plus sick leaves, offs, training time, office events, party - they actually work for about 220 days.
Hold on - 220 are working days.
Assuming their project manager and management goofed up metrics and made their employees work for about 12 hours a working day during those working days, it brings down the actual number of days they worked in an year to 110 days.
Does 110 days make an year?
Well, it may but I am wondering in which planet would that be.
If in one year they actually are at office for 110 days then for 10 years their stay at office is 110 x 10 = 1100 days.
Now how many years of experience does someone who claims to have 10 years of experience has = 1100 / 365.25 = 3.01 years.
Now how much time does a person stays productive out of the 12 hours we calculated?
(You figure out further questions)
Assuming someone hanged around for 5 years ( their idea of an year ) , get promoted to Test Lead and stop running tests. How much time did they actually spend running tests? About an year?
Isn't that their true software test execution experience?
That's why those people who have a problem in my class have more than a problem - with my age and with my questioning skill that makes them feel they are just 3 years of experience and not the huge number that they claim.
"Experience is not the time that has elapsed by. It is what you have done to the time that has elapsed by" - Attributed to some great soul whose name I am unable to find through Google search. This quote impacted my teenage and future thereafter.
Also, that's why people like Michael Bolton, Jerry Weinberg, James Bach, Cem Kaner, Ben Simo, Scott Barber, Jonathan Kohl, Shrini Kulkarni ... are more experienced than what some of us can ever achieve working 110 days an year.
You may continue to say your experience in number of years because it makes you feel good or talk about the things you did and let people figure out what your experience is.
After I finished the workshop and came out of my client's office, I saw someone holding a book "Effective methods of software testing" and I asked her, "Do you know of any ineffective methods to test software?" and her immediate question was: What experience do you have?
My reply : Five million four hundred and thirty six mistakes that I learnt from.
Her response: WHAT!
I definitely might have sounded stupid to her but certainly not as stupid as mentioning I have 10 years of experience although my true stay time at office was 3 years.
--
Pradeep Soundararajan - http://testertested.blogspot.com - http://www.viddler.com/explore/testertested
Question of the day: Did you read copyrights section in this blog?
I am young and will remain young. Some people who sit in my class have a problem with my age. Some people who sit in my class have a problem with their age. They see me as young as they were about a decade ago or half a decade ago and wonder what would I be able to teach them.
This makes my job all the more challenging. I try to crack tough nuts even before I get started off with my class. One such thing happened 2 weeks back in Pune while training for a corporate client when a Test Lead attempted to walk out of my class yelling "this is the most useless class I have ever taken".
Well, I just wondered if he ever walked out of a movie just watching the first minute and deciding the whole movie was useless?
Jerry Weinberg said "Words just carry 10% and the rest is music", which is so true.
I infer from the kind of music I heard from him and the number of white hair he had grown, the problem was not with the class but with his age and mine. Do you ever go out and say "Well, you are inexperienced to teach me?" Don't you just show that in the behavior?
That evening I was conversing about the incident with Manoj Nair and was trying to question "The number of years of experience syndrome".
How many days make an year?
365. 25 ( that's three sixty five and a quarter days )
How many hours make a day?
24 hours ( that's twenty four hours )
When you ask someone about their experience, what metric do they use?
X Number of years of experience
Is that true?
When people say I have 10 years of experience:
Are they trying to say, they worked for 365.25 x 10 = 3652.5 days
Are they trying to say, they worked for 3652.5 x 24 = 87660 hours
We all know that Saturdays and Sundays are holidays and we also have a leave/holiday package an employer gives to all its employees.
So, for those who claim 10 years of experience, ignoring Saturdays, Sundays and average leave/holiday package of 30 days per year plus sick leaves, offs, training time, office events, party - they actually work for about 220 days.
Hold on - 220 are working days.
Assuming their project manager and management goofed up metrics and made their employees work for about 12 hours a working day during those working days, it brings down the actual number of days they worked in an year to 110 days.
Does 110 days make an year?
Well, it may but I am wondering in which planet would that be.
If in one year they actually are at office for 110 days then for 10 years their stay at office is 110 x 10 = 1100 days.
Now how many years of experience does someone who claims to have 10 years of experience has = 1100 / 365.25 = 3.01 years.
Now how much time does a person stays productive out of the 12 hours we calculated?
(You figure out further questions)
Assuming someone hanged around for 5 years ( their idea of an year ) , get promoted to Test Lead and stop running tests. How much time did they actually spend running tests? About an year?
Isn't that their true software test execution experience?
That's why those people who have a problem in my class have more than a problem - with my age and with my questioning skill that makes them feel they are just 3 years of experience and not the huge number that they claim.
"Experience is not the time that has elapsed by. It is what you have done to the time that has elapsed by" - Attributed to some great soul whose name I am unable to find through Google search. This quote impacted my teenage and future thereafter.
Also, that's why people like Michael Bolton, Jerry Weinberg, James Bach, Cem Kaner, Ben Simo, Scott Barber, Jonathan Kohl, Shrini Kulkarni ... are more experienced than what some of us can ever achieve working 110 days an year.
You may continue to say your experience in number of years because it makes you feel good or talk about the things you did and let people figure out what your experience is.
After I finished the workshop and came out of my client's office, I saw someone holding a book "Effective methods of software testing" and I asked her, "Do you know of any ineffective methods to test software?" and her immediate question was: What experience do you have?
My reply : Five million four hundred and thirty six mistakes that I learnt from.
Her response: WHAT!
I definitely might have sounded stupid to her but certainly not as stupid as mentioning I have 10 years of experience although my true stay time at office was 3 years.
--
Pradeep Soundararajan - http://testertested.blogspot.com - http://www.viddler.com/explore/testertested
Question of the day: Did you read copyrights section in this blog?
Labels
bad testing,
creative ideas,
job,
learning,
test consulting,
training,
workshop
Wednesday, October 22, 2008
Your search for Bug Free Software ends here
Test 2008 was a scintillating software testing conference. I never slept before 2 AM every night around the conference dates. I had great discussions with interesting testing minds like Rahul Verma, Aswin Palaparthi, Shrini Kulkarni, Dhanashekaran , Ravindran, Shyam Sridhar and others.
During one of our conversations the topic of "bug free software" popped up and someone mentioned that he had hope to see bug free software within his life span as technology is growing rapidly.
I have heard a lot of people talk about bug free software so have you. What have your replies to them been? Have you been one such who hoped for bug free software?
Here are my answers:
Here is another example - I am a perfect thinker.
--
Pradeep Soundararajan - http://testertested.blogspot.com - 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." --Yours truly
During one of our conversations the topic of "bug free software" popped up and someone mentioned that he had hope to see bug free software within his life span as technology is growing rapidly.
I have heard a lot of people talk about bug free software so have you. What have your replies to them been? Have you been one such who hoped for bug free software?
Here are my answers:
- Oh yeah, you don't need to wait for the technology to advance, bug free software already exists. Have you shipped software products to your customers? Were there bugs in the products you shipped? Did you charge your customers for the bugs? Did you make the bugs free for them? So, you did ship a bug free software! So, all software we ship is bug free!
- I shall give you the link to download a software that remains in bug free state in a specific context. Unfortunately the bugs start showing up if you try downloading the file, opening the file, install the software or start using it. I can guarantee you its bug free if you don't do anything of that sort with it.
- It might be a good idea to read Jerry Weinberg's book on Perfect Software and other Illusions about Testing in which he makes an attempt to make some of us conscious of the fact that - humans are imperfect thinkers, how can you expect an imperfect thinker to produce something that is perfect?
- I think, even, accidentally humans can't produce bug free software. The idea of bug free software itself is the result of imperfect thinking and imperfect understanding of software and bugs. We might end up making better inferences and conjectures about what they are if we are on a continuous learning path.
- "Software systems can easily become complex. Computers allow us mortals to create complex systems that are beyond our ability to fully understand. We testers seek out software problems based on what we understand. We cannot completely test the software. We use a variety of tools and approaches to learn as much as possible. However, we are unlikely to completely understand a complex software system." - Ben Simo
Here is another example - I am a perfect thinker.
--
Pradeep Soundararajan - http://testertested.blogspot.com - 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." --Yours truly
Monday, September 15, 2008
Exploratory Software Testing Demonstration Videos
You have read enough things from Pradeep Soundararajan. Some of you even believed what he wrote. Some of you thought it was stupid. Some of you follow it very closely. Some of you got irritated by it. Some of you relied on what he wrote for guidance. Some of you enjoyed the writing and others hated it. Some of you thought he was faking. Some of you didn't bother to read what he was writing all these days. Some of you thought he is talking about ideal world. Some of you thought what he talks isn't practical. Some of you will always think good or bad about him no matter what he does. No matter whatever you think of him, he will keep doing things because what fuels him is, himself, primarily.
Now here is my testing open to public scrutiny. A Rapid Tester stands up to scrutiny. Here is something that can stand up to public scrutiny:
That's just one of the 7 videos I have come out with. If you are reading this post, you could find others as well. 7 isn't my limit but at a start. From now on, every week or two, you could find a new video. Not all of them would be published on my blog so don't rely on my blog to get updates. Figure out a way. Also you could download those videos if you wish to watch it offline or to watch it more than once.
Jonathan Kohl wrote about the importance of testing videos here .
For all things you couldn't believe about exploratory testing, human testing skills, rapid testing, context driven approach, pair testing, etc... here is one of your chances. Alternatively James Bach, Mike Kelly and other testers have their own videos which you could find on Googling.
The horse can be taken near the water. The horse won't drink the water if it thinks its not thirsty or it can live without drinking that water or for whatever reason the horse decides not to drink. I know, you aren't a horse or at least you don't appear so.
If you wish to be a part of these videos, drop an e-mail to me. Thanks to Ajay Balamurugadas and Sharath Byregowda for their enthusiasm in helping me with these videos and for pair and trio testing with me.
Operation Roshan has just begun.
Update: 18 Sep: When we watch a movie, we usually fall in love with the actor and actress and forget the work of people who made the movie to happen being at the backstage. Similarly, I forgot to include our host for about 2 days since I posted this who facilitated the video creation, place, resources and provided space to sleep overnight - Edista Testing Institute and Test Republic. When I asked what Edista means, I got a reply as "Facilitation" and this is an organization living up to what its name means.
Thank you folks!
--
Pradeep Soundararajan - http://testertested.blogspot.com - 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." --
Now here is my testing open to public scrutiny. A Rapid Tester stands up to scrutiny. Here is something that can stand up to public scrutiny:
That's just one of the 7 videos I have come out with. If you are reading this post, you could find others as well. 7 isn't my limit but at a start. From now on, every week or two, you could find a new video. Not all of them would be published on my blog so don't rely on my blog to get updates. Figure out a way. Also you could download those videos if you wish to watch it offline or to watch it more than once.
Jonathan Kohl wrote about the importance of testing videos here .
For all things you couldn't believe about exploratory testing, human testing skills, rapid testing, context driven approach, pair testing, etc... here is one of your chances. Alternatively James Bach, Mike Kelly and other testers have their own videos which you could find on Googling.
The horse can be taken near the water. The horse won't drink the water if it thinks its not thirsty or it can live without drinking that water or for whatever reason the horse decides not to drink. I know, you aren't a horse or at least you don't appear so.
If you wish to be a part of these videos, drop an e-mail to me. Thanks to Ajay Balamurugadas and Sharath Byregowda for their enthusiasm in helping me with these videos and for pair and trio testing with me.
Operation Roshan has just begun.
Update: 18 Sep: When we watch a movie, we usually fall in love with the actor and actress and forget the work of people who made the movie to happen being at the backstage. Similarly, I forgot to include our host for about 2 days since I posted this who facilitated the video creation, place, resources and provided space to sleep overnight - Edista Testing Institute and Test Republic. When I asked what Edista means, I got a reply as "Facilitation" and this is an organization living up to what its name means.
Thank you folks!
--
Pradeep Soundararajan - http://testertested.blogspot.com - 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." --
Subscribe to:
Posts (Atom)