My Technical Blog: 2009

Here i am sharing a post made by Pradeep Soundararajan!

Learning to test better by teaching testing: "Make a list of some of the bad teaching staff you faced at your school or college. You might be able to notice a pattern - most of them were the ones who were not willing to learn while they were teaching.

Case 1

I was teaching at Datamatics 2 weeks before and at the end, a participant asked me, 'What did you learn in these 2 days of workshop?' and 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. As you might have seen my Progress Report, you might also have discovered the list of events that happened to me in 2008 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. Sometimes I have an answer like, '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.

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.

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

Case 2

Lunch tables are great learning ground. At Datamatics, I was joined by a group of testers who were attending the workshop. I ordered for a Dal Kichdi that some other people had ordered. 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 in it and then found more hair. I picked the 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 Saurabh Sahoo, Test Lead at Datamatics asked, 'Do you know why you found the hair while we didn't if it could be there in our Dal Kichdi?', 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 engrossed with looking at the expected result that makes you blind to see other things happening in the environment and 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.

Facing and answering questions like that definitely helps me in negotiating with management and clients.

Case 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 waste class. 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 during these recession times.

I said, '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 by watching the titles of the movie because the titles were not good?'

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 paraphrased the message, 'Either your cup is too small or it is already full of opinions'.

The result is, 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.

Case 4

A common problem that most testers talk about - is being caught for missing a bug when a customer finds it. A tester in 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

Teaching testing to experienced people demands a tester to handle tough situations on the spot. It is easy to teach dull minds that don't oppose and appear to nod for every idea that you share with them but those bright minds are tough and demanding. They teach you a lot about how to test better.

Most people who teach testing in India at several training centers in India haven't done testing at all or haven't done enough testing. So, those who have it gains a competitive edge. You can further keep gaining a competitive edge by continuing to test products because the teaching doesn't restrict you to test and in fact it adds value to your testing.

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?

You might know Sharath Byregowda and Manoj Nair if you have been reading my blog or theirs. They have now stepped up to the above challenge and are joining me as a Consultant at Satisfice India and Edista Testing Institute. Their extensive testing experience is now going to benefit the Indian testing community at first.

If you are a tester and is interested to join a small test group named Satisfice India that specailzes in coaching, consulting, and testing services, write to me. You'd work with some of the upcoming very good minds who care and live for benefitting the software testing community.