How Pradeep teaches software testing - Part 4

If you didn't know how Part 4 came up? Here is how it came. I first wrote Part 1, then Part 2 and then Part 3 ;-) So, logically here is Part 4 of the series How Pradeep teaches software testing.

"I know how to do certain types of testing but if someone asks me to explain what I did, I struggle to explain" was a problem statement I heard from a tester today. I replied in a confident tone, "I know why that happens. It doesn't just appear to be your problem but I know a lot of testers who appear to have the same problem." 

I continued, "You should consciously practice explaining what you did, first to yourself and then to your colleagues although they probably know how and why you did it. Why? I am going to explain how your brain works (or how I think it does). It has two nodes. One that contains what you know and the other that controls your explanation of what you know. When you make a conscious effort, you are forcing a connection between these nodes in your brain. When you force your brain to connect those two nodes too often, at some point it will judge the need for a permanent connection and create it for you. After that you have a free flow of what you know and your explanation of what you know." 

After I said the above, I could see a smile in the face that reflects, "Yes, I now know how to solve this problem". I read a person's understanding not by their head nodding or when I hear, "I get it", but by the emotions and expressions on their face and the body. 

James Bach identified that I was a metacog. I didn't know I was one. After that, it has been very helpful for me to understand why I do things the way I do. I guess I turned myself into a metacog because I thought it suits the kind of testing I wanted to. It's not a special status, it is just a way of life.

I don't even know if the brain works the way I explained it to be but I guess you can understand why the above explanation makes sense. I make sure I tell people that I am not trying to misinform them about anything when I use such examples. I am just helping the tester imagine why there is a problem and how to solve it. A lot of my coaching is consulting.

Examples like the one you read above govern a major part of my coaching. I observe a lot. I practiced consciously making connections between what I have seen, heard, thought, experienced and know to being explain it when the context demands.

Analogies and Examples are powerful approaches to teaching. I need to know what connects to my audience very well. Although all my audience are testers, I can't use the same analogies and examples, it just doesn't work. Bangalore testers need a different example than those in Pune. In Pune, I would talk about Raj Thackery and in Bangalore I would talk about Vattal Nagraj, in Chennai about Goundamani and not about Vattal Nagraj. Now, for those of my readers from United States or Europe, you wouldn't know Goundamani or Vattal Nagraj and hence I would use examples of Chuck Norris, Sarah Palin, Julian Assange. If you are a F1 fan, I'd talk about testing through specific GP incidents. That's how the examples need to adopt based on audience. I also use a lot of examples from what I think the world connects to. For instance, I closely read and watch Air Crash Investigation in Nat Geo channel. OMG! There is so much to learn from the way NTSB (National Transportation Safety Board) deals with it. So, basically as a coach, I have to keep connecting to various thoughts and happenings to be able to connect with my audience. 

Similes, Metaphor or if you choose to call them Analogies are interesting and tough piece of cake, if you are the one providing it. People tend to take it in their own interpretation than what you intend to. It is good in a way, I get to learn when not to use what type of analogies to what kind of people :)

I use Fishing for explaining test coverage. I know a few other people have already used fishing as an example for teaching testing, so I didn't invent it but I know how to explain different concepts of testing with the fishing example. I think that most learning happens when you are interacting with the audience and not when you are explaining. That's where I do better with the fishing analogy.

I start drawing different types of fish, from guppies to clowns and from star fish to sharks. I then draw a size and shape of a specific type of net to catch fish. I give them a goal of catching as many different fish as possible in a limited amount of time. Some audience come back and tell me, "Ah with this net the guppies will escape"... what's your immediate thought? You would tell them to build a net that has smaller squares to catch guppies?  (Why say it? They know it) I would probably be Pradeep and say, "Fantastic. A lot of time spent celebrating the success of finding one good bug steals away the opportunity to find more good bugs. How do you want to celebrate? 3 minutes left."

So, after they come out with strategy and different nets, I tell people that just because they have nets (tools) to catch a specific type of fish it doesn't mean they can really catch a plenty of it. I then tell a story and examples from my life. One of them: I consulted for an organization who had bought an expensive automation tool hoping that they would now be able to find more bugs. They spent all their energy to set up tests on it and found fewer bugs over the year. I drive points like: Tools don't help you unless you know how to help the tools to do what you think they can.

For a while people think it is possible to catch a shark from a net. It is possible, maybe. I explain how a powerful shark can bring their boat down if they try to catch it through a net or a fishing rod and how a harpoon is better than a net. Sometimes people try to think of similar approaches to solve many different problems. The example of shark, net and harpoons are cool for people to relate to something they have done in the past that shouldn't have been done the way they did it. I then equate different types of fish to different quality criteria. I ask my audience what type of fish are they mostly catching and I hear a shout, "Functionality". 

After a lot of back and forth between me and my audience, we all discover what good test coverage could mean. I then start probing into their projects and figure out how much of fish they are missing that they shouldn't be and try to help them understand why they shouldn't be catching too much of the same fish. Sometimes it upsets the food chain :) 

While there is fishing in my class, there is also plenty of room for Sine and Cosine for Test Techniques, Brian Marick's Minefield Analogy for Regression Test Strategy, Tom and Jerry examples for How Scripted Testing is dangerous, what lessons can we learn from Saurav Ganguly's come back, how to read Sachin and Kambli's career graphs, farming... It must be fun to sit in my class. I don't know, I have never been able to.

Happy New Year!

How Pradeep teaches software testing - Part 3

I hope you have read Part 1 and Part 2 of the series of "How Pradeep teaches software testing" and I welcome you to the Part 3. I don't yet know how many parts it is going to take for me to complete this series. I am hoping that I would write down the most important parts and keep adding whenever I need to update. In this part, I am going to focus on my journey of doing exercises and hands on stuff I do at my workshops.

Having been a guinea pig of James Bach and Michael Bolton's online coaching, I myself went through quite a few exercises that were under experimentation. I still remember James showing me a set of pens and then hiding all of them away from me but one to ask me which one was being shown to me. All of them looked identical so it was difficult to tell which pen was he showing me. I had to figure out a way to question him to help me identify the difference between those pens. This is one such exercise that didn't make it to the Rapid Software Testing class. However, I benefited from all of them.

When I started to teach my own version of Rapid Software Testing in India, I sought permission to use a few exercises from the original version. I got permitted to use the Mysterious Spherical Ball and Dice Game. Oh, the Triangle, too. I needed more and I had to create my own.

Even before that, I had to modify the exercises to suit me and the point I wanted to drive. I did that. I have a few variations of the game and exercises and at times I drive a different point from the original one. If I were to have been a parrot repeating what they taught me, I wouldn't have been able to survive or inspire people.

I tried my own exercises. I tried them out with James & Michael. It was hard to teach them back something with my exercises. That made my exercises or my ability to deal with them stronger. I then tried it out on a couple of testers here in India and it worked wonders. So, I consciously didn't take all of my exercises to James & Michael. Not that I wanted to avoid them but as their good student, I wanted to appreciate their time. I first wanted to get good at something before asking them to work on it.

I published some exercises on my blog. For instance the telephone puzzle and other brainstorming exercises helped me to experiment some of my own.

Every time I did the same exercise with new batch of testers, a new idea or an approach used to emerge that used to teach me a lot. I started to focus on what testers in India need to learn. If their fundamental is flawed then it is not good to teach them some things that appear to be Greek and Latin.

I made a list of things that I think is fundamental and started to work towards exercises for the same.

I am listing a few of them below

Skills

• Observation
• Questioning
• Lateral Thinking
• Reverse Engineering
• Scripting
• Investigation

Technical

• Test coverage
• Testability
• Mission focus
• Heuristics & Oracles
• Bug Reporting

I built exercises for each category I wanted testers to get good at. As an example, I built an exercise for reverse engineering practice for testers: Finding Nemo  . Sorry to Mac folks unless they have a Windows emulator in it.

I wondered if I could really help in creating good testers with my crazy set of exercises and ideas. I was consulting for Edista Testing Institute and sought an opportunity to experiment my crazy ideas with two batches of fresh college graduates. The results were beyond imagination. I could bet on these testers against all of the ISTQB passed fresh college graduates put together. Here are excerpts of the work that they produced after a month of training from me. 

I was all the more convinced about creating my own exercises to help creating good testers in India. As an evidence of how skilled a tester could get beyond those 30 days is here - Santhosh Tuppad, my student of the fresh college graduate training is now a co-founder of Moolya Software Testing Private Limited. Not just he, other testers from those batches are top testers in the organization they are working for. There are a few in them who haven't yet made it large but if you talk to them you'd know it may happen, if not today, tomorrow.

He is the youngest testing entrepreneur to the best of my knowledge at the age of 23 and this story being created in India and me playing a small role in it makes me happy of the path I am heading towards in coaching software testers. I am specifically going to write about my students and their journey after attending my training in a part dedicated to them.

The exercises created curiosity in them to learn more. So, I didn't do the learning for them, they did it for themselves. What every training for a software tester needs to do - is to create curiosity with pointers of how they could do it. What ISTQB is doing is a super reverse of that. They damage the gene when it is being built and create business opportunities to themselves in the context of helping such genes upgrade and repair.

Some of the ISTQB trainers in India who perceive that my work has an influence on them, use some of my exercises in their workshop. I allow them to do so because that's the best hope for me that someone would then question the value of what is being taught as ISTQB and get curious to learn about testing.

My exercises teach people to test their own ideas of testing. I'd like to build thousands of them and give it away. Over the last few years, I have seen lot of action from Context Driven Testing folks on the exercises. People come up with their own exercises and share it with others. It is the safest community to be in irrespective of whether you agree to the principles or not. People like Sebi, Markus Gaertner, Matt Heusser are the ones on top of my head who contribute testing exercises to the world.

You will have fun cracking my Finding Nemo exercise. You would trick yourself to believing you have cracked it and then if you do a few more tests, you'd discover you haven't. Santhosh and I worked on something called Guess the Password - Version 1 & Version 2 . Don't go to Version 2.0 before completing Version 1.0.

This is what I am doing in India. This is how I coach testers. The future is all about such testing exercises, if it were to be a bright one. So, all of India isn't all that bad in testing as you may be imagining it to be. Note that!

In future parts of the series, I am going to be covering on aspects of my interaction with testers in the class, humor that works for me in my class, feedback and what I did with it, interacting with trainers in software testing and lots more. Stay tuned, it looks to be completely safe.

How Pradeep teaches software testing - Part 2

I just hope you all read Part 1 of this series. Now, I bring to you Part 2 where I talk about my journey of my first set of workshops.

In 2007, I was not sure if people would be willing to listen to my ideas in testing. I had some good readership for my blog and I announced 2 hour free talk on exploratory testing titled Mirchi Test Masala. Mirchi in Hindi means "spicy" and I wanted to offer the Indian Spicy Testing flavor during my talk. By God's grace, I was flooded with interest from my blog readers to host me for this talk at their organizations.

I happened to be invited in companies like Dell, Huawei, Celstream, Ionidea, Hasten Technologies and even at an organization in Chennai. There were few more organizations who happened to invite me a couple of months later looking at the blog post. I forgot some of their names. It could have been big or small ones.

This was an opportunity for me to test my public speaking skills, my ability to coach testers and also a test of how influential I could be to testers. I used a bug in Microsoft Powerpoint 2003 as an exercise to drive certain points to the audience and help them see testing as an exploration than merely test case execution.

This also gave me an opportunity to face some tough questions from audience and there was a stiff resistance to my ideas. Being an outspoken context driven tester in India wasn't one bit easy. There was a huge wave against the ideas I was trying to spread. Whatever resistance I faced didn't matter much because people saw an extreme passion for testing in me and they were acknowledging it well. That was a huge boost to my confidence that I can actually do a full day workshop.

I guess in early 2007, Michael Bolton did a Rapid Software Testing training for a client in Bangalore. That client had chosen a venue for coaching which was "rent a training room" types. I decided that I should do my first workshop in the same place because the vibrations that Michael left there would help me boost my confidence. I payed a lot of money to book the same room. That is where I did my first workshop on Exploratory Testing.

I was surprised (yeah, I was) that there were about 17 people who were willing to pay as much as 3500 INR for a day to get trained by me. I guess I paid more than half of that money on rental of the training room but I was happy. I don't distribute feedback forms because I believe the actual feedback is when people go back to their workstations and test out the new ideas.

Somehow, people were convinced that I was giving them a different perspective. My workshop was mostly hands on. Minutes before I started my workshop I pinged Michael and said, "I need your blessings on this important day in my life. I am nervous" and he replied, "Are you an expert presenter?" and I answered, "No". He then said this great thing, "Well then pretend to be an expert presenter". That helped me so much that I pretended to be an awesome presenter. Over the years, I have developed a stage presence that audience have loved it in most occasions.

What I seemed to gain is many different ways to run the same exercise. However, my audience were my asset. They asked so many questions to me that helped me do a lot better thinking to help them learn what they wanted to. Sometimes I appear to people as the king of analogy and examples. I connect with my audience well because there were my audience of past who taught me so much about how to do it and how many different ways I could fail trying to give an analogy.

There is at least one good thing I tell in all my workshops: If you want to disagree with what I am saying and stay silent just because you don't care about me, you are killing the testing community indirectly. I am going to be doing these workshops to many other testers and I don't want to keep telling stupid stuff to them, so please help me.

That statement has helped some people tell me where I am bad and where I need to do better. After I engage them in a conversation and if I was convinced about it, I made necessary changes.

A big thank you to all those who attended my first set of workshops. You made this guy grow in confidence and helped him learn how bad he is and how good he needs to get. The most useful feedback has mostly not been on feedback forms.