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.

Story of how a hang becomes a crash (because testers love reporting crashes)

I am doing my first exploratory testing workshop for 2011 and first from Moolya Software Testing Pvt Ltd. and I am excited about it. You can find the details by clicking on this link . If you are in India and plan to attend it, please do it quickly. I usually don't take a lot of participants although I know I'd gain more money out of more participants. Ever since I announced it yesterday, there are 4 seats that got filled within 5 hours.


Now, I am going to tell you a story that I had been hiding for quite a while. Not intentionally hiding but was planning to blog about it and the time is right now :)


I provide many applications to test in my workshop. At the end of a testing session, I check with the participants if they found any crashes with the application. Not to be surprised, a room full of testers, they do report crashes.


I ask them to reproduce it with me watching what they do and here is a shocking information; most of what they report as crash weren't crashes at all. What you are about to read is also a great example of confirmation bias that I have witnessed.


Here is what they are doing: They are performing an input constraint attack or providing a large set of characters as an input to a field and hits the "Submit" button. They wait for 10 seconds to see what the application does and on seeing the application in not responding state, kill the application and report that as a crash. 


Awesome! Isn't it?


Now, I got conscious of the fact that testers seem to be reporting a hang as a crash and was keen in looking at live projects during my consulting assignments. I get access to the bug tracking system during my consulting (wow) and I see patterns of such reports. 


I go filter out some of the crash reports from the bug tracking system and try to attempt what the tester did to report that type of a crash and bang, that's a hang.


I have made this point to testers who attend my workshop in order to help them be more conscious of what they are seeing versus what they are reporting versus what they are eager to report versus what they should be reporting. 


It seems to me that testers have an anxiety to report crashes. There's nothing wrong in it but it goes horribly wrong when you report a crash by fooling yourselves and the people around you. I recently blogged about the Obsessive Checking if being mentioned disorder that I was suffering from and here is a relevant excerpt from it, "Months later, I started replacing every word by my name till I saw my name on others post. So, I may have read a few posts without actually learning anything from it because all I saw is "Pradeep" & "Tester Tested" on those posts."


Now, why is that relevant to this post? I see that the testers I have witnessed who report hangs as crashes also appear to have a similar problem of obsession towards reporting crashes that they appear to not see a hang but see a crash. I would love if you ask if these testers ever report a hang? Yes, they do. If an application recovers before they kill, that's a hang.


I understand that an application might have hanged because it has crashed but how do you know? Oh yeah, allowing the GUI to fool you and me?


Here is an excerpt ( and tweaked to hide confidential information ) from an issue that I reported on Sep 30, 2010 @ 12: 13 PM IST (thank you Jira) while testing a new OS that is soon to be launched. No, not Chrome OS.


"I opened Media Player application and made an attempt to subscribe to a podcast. 
The application appeared to hang and it also did not allow me to close using the X mark on top right corner.


In an attempt to kill it, I navigated to XXXXX (product name masked) and tried closing it from there. However, the XXXX is open and Media player still seems to be remaining in the hung state.


From that point, I might be forced to reboot the system to get out of it or can escape by waiting for a longer time that I waited for Media Player to recover (>5 mins). No user to my knowledge would wait for more than 5 mins to see the Media Player function. Even a reboot appears to be a faster option" 

Now, if that was the Description, here is the summary :

"Unable to kill a XXXX when the application in it appears to hang or is busy"

• Why I posted the above? Is it because I wanted people to note the usage of the word "appears"?
• Why did I make a few words in it bold? Is it to highlight it?

Long ago, well, not so long ago, I blogged about how teaching testing is helping me test better. The above post and the bug report I posted, is another example of how teaching testers has helped me do it a lil better.


Now if you are going to be sitting at my workshop and be worried if you are going to make mistakes that I am going to highlight, please be informed that you are paying to my workshop to get into the safest environment to fail. No managers watching you. No clients frowning at you. No appraisals being done. Just your own dream of personal excellence aching you for not being there yet but being happy that you know why you are not there. Its a wonderful feeling.


Now, for some marketing again :) You can find the details of my upcoming exploratory testing workshop titled "Accountable & Manageable Exploratory Testing" by clicking on this link 


Happy Republic Day folks!

Test coverage : Life beyond functionality

At a class recently 

Scene 1:

"What have you all been doing for the last few years in this organization?"

Chorus: "We test for functionality of the software?"

"That's nice! Why do you think it is called /functionality/?"

Silence

"OK, what is a function?"

Silence

"No problem. Let's fix it. Where else have you heard the word /function/? Math? So we all might have studied f(x) = y and that could have been our introduction to working with functions. Later we moved on to parabolas and hyperbolas which had functions of different behavior and complexity. So what we are doing when we say /functional testing/ is, we provide inputs X to a function f(X) and monitor Y. We claim to know that f(X) should be Y and we also claim to know the range of Y. So, that forms our oracle to find bugs with functional testing. /Y/ doesn't necessarily need to be a numeric value in functional software testing".

Scene 2:

"So, what else do you test beyond functionality?"

• "Our bug reports get rejected if we report non functional bugs so we don't test for it", 
• "There is a team in US who is supposed to do it"
• "When we find a non functional bug and report it, we are asked why did we spend time deviating from the scope given to us"
• "We have enough test cases in functional testing that we don't have time for other kinds of testing"

"Are you doing Quality Assurance or Software Testing?"

"What?"

"Let me explain. In Software Testing, you provide quality related information to help the management take better informed decisions. I think in Quality Assurance, you claim to provide confidence to the management that you have checked and tested a lot of things (not just software) and things didn't change after your checks and hence its OK to use the word /assure/ with another word /quality/."

• "I think we do a mix of both"
• "Our designation is Software Tester but we are internally called QA"
• "I don't know. I am doing my job and earning my paycheck"
• "Yikes, this is confusing"
• "I thought Testing == QA" 

 Scene 3:

 "I appreciate the diversity. Tying it back to our previous topic, irrespective of what you do (Functional Testing or Functional QA, the information you provide to your management is so weak as compared to what you were supposed to be doing."

"How is that?"

"Test coverage is the extent to which we have modeled and tested the system -- Michael Bolton. You appear to have modeled the system for functionality and you could model your system in more ways within and beyond the scope of functionality to learn more about the product and to be of more value to your management. Assuming you are interested to do that. Here is a list of thing that you might want to focus on:

Product Elements Coverage

• Data
• Platforms
• Operations
• Time
• Structure
• Functions

Quality Criteria Coverage

• Capability
• Reliability
• Usability
• Scalability
• Performance
• Installability
• Compatibility
• Supportability
• Testability
• Maintainability
• Portability
• Localizability

Technique Coverage

• Scenario based
• Claims based
• User based
• Flow based

( refer to Rapid Software Testing slides for more )


"That looks like a lot of thing to do and I know these are important for quality. We don't have time for functionality and how can we think about all these things?"

That's a nice thing that you realize you don't have time even for functional testing to be done. How about asking the management to re design and re think about the time that is given to you and the value you can deliver?

Scene 4:


"I know for sure. They won't allow us to do all this"

"Interesting. Is that your assumption or a fact?"


"That's what is going to happen if we ask and we know that."

"Have you tried it?"


"No, but we know them very well."

"How much do you think they know about you and your skills?"

"They hardly know about me and my skills."

"So do you about them. If they assume you are not skilled to do other kinds of testing and also assume you heard them say /We are sure, they don't know to test beyond functionality/, how would you react to it?"

"I would show to them that I can"

"How about giving them a chance to show that they too can change?"

Silence

Two things:

• Give each of your colleague a chance, explain to them your problem.
• Give yourself a chance, focus on your test coverage and explore a life beyond functionality.

Coaching testers on Bug Reports, Advocacy & Credibility

Here are some of the funny/awful bug reports that I have seen in my experience:

• "When I open the application and click on that button I get a error massage saying it fatally crashed"
• "The spelling of Transport Parametre is miss spelled"
• "When I perform a submit the application has error message and thrown on the right side"
• "I open and it crashes"
• "The application is giving me unexpected message to work"
• "Clicking on that link is taking me somewhere and I am unable to return"
• "Applications is throwing pops up when I put my mouse on links of ads"
• "Click fast links and get error message"
• When trying to establish connection with devices some device say I am not available
• Everytime I execute test case TR234 my PC rebooting
• Test case TR 343 fails
• When users click Submit twice & hangs.
• After waking from sleep, application don't respond. (Hope you got what the tester was trying to say)

Impact

• Now, that's funny for the moment but what about the credibility of such testers? 
• Why would they be respected? 
• Why would their bug reports be even read further? 
• Why would they need a hike? 
• Why wouldn't they be treated not on par with others? 

Unfortunately, more number of such bug reports have made developers sick of reading bug reports. That's why you'd see developers call testers to their desk and say "Show me that bug". I am concerned about this problem because it is yours and mine. When we who report bugs in a credible manner join a team and report bugs, the developers still ask, "Show me that bug". That's how bad the effect has been on most developers that I have come across in India. Other country folks reading this could share their experience.


Bug reports are one of the key factors that make or break the credibility for testers.



You know about Hands on Software Testing Training from India? If you haven't, you must take a look at the excerpts of students work. You might be surprised and ask me if fresh college graduates from India really reported such bugs in such a credible way.

Santhosh Tuppad, a tester who chose me as his mentor, striked this distinction - he was profiled at Utest for gaining credibility for the highest bug approval rate. You should read about it, I think.

Santhosh, just has an year of experience. However, the practice he did, in that one year, is what has made him get profiled at utest and win the credibility of the highest bug approval rate. Not just Santhosh, his batch mates are doing exceptional as testers /for their year of experience/ in the organization they work for. That even includes his girl friend :)

I just did what any training is actually supposed to do. So, I am not going to be bragging about myself or about the magic / voodoo stuff of coaching testers. Its safe, you can read it without getting hurt.


Its a shame that some of us are being looked upon as good thinkers for just doing what every tester is supposed to be doing. That's the state in which our community is. I think the difference is that we /those who are considered good thinkers/ are bolder, respect ethics, have higher self respect and want to see the community better.

Let me just share how I coached testers on bug reporting and bug advocacy, so that it could either help you coach yourself or others. The ideas to coach testers that I have is abstracted, borrowed, redesigned, modified from what I observed while getting coached by James Bach & Michael Bolton. I also did a context driven approach to suit India.

Coaching testers to report bugs

There is a one week of training & practice session on Bug Reporting in my Hands on Testing Training class. In typical approaches like ISTQB, CSTE training, they appear to cover it up in 2 hours or less. Wow! Those guys have scalability and I don't.


So, I set up the bug tracking system, provide them a buggy application (mostly any software) and ask them to report all bugs they see. I clearly state that it is not about who finds the most number of bugs but who reports bugs in a credible manner. I don't teach anything about bug reporting when I start this exercise and leave it to them to learn it through the experential approach.



I am logged in as admin from my laptop. The first bug report arrives and I call that participant to my seat. I critique the report in following ways:

The developer view

"I am a developer and I don't understand your bug report. I don't know if this is happening while running in Vista because I see a different behavior in XP. As you have no indication to me about your OS, I have no clue what to do with your report. This is why I don't understand your bug report. I am deleting this report because it doesn't make sense to me. Can you report it again in a way I can understand it?"

• The participant goes back and attempts to report the same bug with additional points based on what I mentioned.
• That participant whispers the message across to other participants and I just act as though I don't know about the whisper.
  

Some kinda smart people pick up a little more and mention other details such as Service Pack 2/3 so that their bug report doesn't get deleted again but others don't get it yet. No problems, Pradeep is there to help.

The next bug from another participant arrives and also gets invited to my seat. "I am a developer who is sitting in US of A and I can't understand your English. Maybe it would help me if you could send me a screenshot or a video. I am going to delete your bug report as I don't find it helpful to me.

•  So, that participant goes back with a little disappointment that although the System configuration was mentioned, the bug report was deleted.
• Whispers about screenshot and videos gets started. I didn't hear any such whisper :)

The next bug from another participant with system configuration and screenshot. A 6 MB BMP attachment."I am working in a dial up connection and this attachment is taking 20 minutes to download. I have lost my interest to see the screenshot. Maybe you logged a great bug but I would have been able to see it if it were a JPG file that takes lesser space"

• Whisper! Sssssh!
• I don't know :)

Another bug, another participant. Spelling and grammatical mistakes, filled and stuffed in the report. "Thanks for coming to my seat when I asked you to come. It shows the respect you have for me. I wish I could respect you that much or maybe even more. However, I see that your English looks so bad that my colleagues would laugh at me if I respect you. In order to prevent that from happening, I have no option than to delete your bug report"

• "Hey, please correct this report" whispers one to another.
• I then announce "Microsoft spelling and Grammar check is your best friend".

As a Developer who loves to say, "No user would do that"


"Hey, the bugs you have reported are not actually bugs. So, I am deleting them all".
"What? Sir, we put in so much of effort and you are deleting it all" (Hate the "Sir" part though)


Well, if you'd not want to me to delete any of your bug report then I need strong evidence and investigation of why you think it is a problem. I wish I knew which Oracle you used but none of you reported any such.

• At this moment, I hear people wondering what oracle they used to spot the problem and trying to add to their existing bug reports.
• I announce, "You could ask me which oracle if you are not sure". For the next 15 minutes I am your friend who knows how to test and the oracles for the bugs you reported.
• Those 15 minutes is real busy time for me.

Next iteration. "The oracles you mentioned seem to be OK but I am still not convinced if that is a problem. It might help me understand the problem if you could tell me the impact it has on the user. Hello! Bug Advocacy! Cem Kaner! Google!"



So that goes on and on and it takes them 3 days to get one bug report to not get deleted by the developer. By then they have surpassed most of the ISTQB, CSTE or any other similar certification training. However this approach that I am talking about here sucks. Man! it doesn't have scale.



As Test Manager


So, from today I am a Test Manager. Not a developer. I hear a sigh of relief. They think their reports wont be deleted as much as it did with the Developer.



"Ah! My manager has called me for a meeting to give an update. When I look into all your bug reports, I get no clue what it means. Your summary is either too long or I am unable to understand them. I don't have time to go through your bug reports in detail. I shall delete all bug reports that do not help me make a quick assessment of the quality of the product"


"Hey! Here is how I report bugs!"

• No Whispers this time.
• They start copying my style and when they are learning it for the first time, that's Okay.
• All bug reports gets changed to a style that I follow.
• The beauty comes when some people try to modify my style to their own style. That's the Indian Masala I like the most.
  

Now, that kind of thing happens for a few iterations and it goes for one full day or so, till I am satisfied about their bug reporting as a test manager.


As a co-learner


"Guys and gals. Now, we are pretty OK with bug reporting and bug advocacy. Let's try to critique the bug reports that are public and try to learn if there is something interesting that others do that we didn't so far"


I open bugzilla.mozilla.com and go through many reports and ask them to point out the good and bad points in the bug report that we are observing. We have a discussion, argument and debates on it. So, we end up refining ourselves and I drive home some important points of bug reporting.


"Folks! Lets test your bug reporting skill. Let's work on another project and see if we repeat any mistakes or make new ones".


Fail fast, Fail Safe


I failed miserably in a couple of exercises that James and Michael did with me as a part of Rapid Software Testing. However, for me, it was safe to fail in front of them than to fail in front of a client. I was glad I was exposed to a context that I failed although that kind of context had not been on my work yet. When the context actually arrived, I said, "Aha! The Wine Glass". Its a RST secret :)


I have a checklist of things I would make the participants fail and get them corrected of it with respect to bug reporting and here are some of them:

• Spelling, Grammar & Typos checks
  
• No usage of SMS language
• Crispy & Useful summary
• Serving different stakeholders
• Observations
• Investigation
• Risk to the user
• Inferences & Conjectures
• Cost versus value
• Screenshots & Videos
• Log files & Supportability
• Symptom versus problem
• Cost of fixing / not fixing the bug
  
• Questions to the developer
  
• System, Browser and all other relevant configuration
• Test Environment awareness & details
• Self critique of ideas and bug reports
  
• Peer review
• Input / Output / In between : test data, system state, environmental changes
• Hardware

Enough! You might ask me how big is my bug report usually. Well, it depends on the bug and the audience not on me. In the last two assignments that I am executing here in Delhi, a light weight bug reporting with all above information is helping me win accolades. Sorry for bragging although I said I won't. Its kinda bad habit, you see.


Oh, you know, I also won the Top Best Bug at Utest in the Bug Battle of Search Engines. I wish Utest could publish that bug report. Since then, I see some testers attaching videos of their bug in utest bug battles and releases. It really solves the problem of language barriers, steps to reproduce for most of the bugs. I didn't invent the idea of video recording bugs but I practice it and advocate it to be used in contexts where it helps.



So, coming back to the topic of Bug Reporting, Bug Advocacy & Credibility. So, are you surprised that Santhosh Tuppad who went through such a training achieved the status of highest bug approval from Utest and is invited to many more releases to test?


Whenever I go and speak to businessmen in India with the results of this kind of training approach and the value it can bring to the community the thing they say after saying "Great" is "This doesn't have as much scale as ISTQB or CSTE where I can make any Tom Sick Hary to replicate the training. Slides are replicate-able. Good luck".


So the message to you is.Forget all this hands on approach and other blah blah. ISTQB has scale. CSTE has scale. CSQA has scale. ISEB has scale.Go there and learn to memorize the CBOK and practice to puke it on the exam.


I don't coach people to memorize. That's not how I was coached. Go find a guru who would teach you good stuff. Don't waste time with businessmen talking about a stuff that they too know is good but they think won't scale.


I will show the world that good stuff can scale. If you didn't like the word "I", let me replace it by another.


"We will show the world that good stuff can scale".



The Avatar!

Title 1: Investment plans for software testers. Title 2: Michael Bolton RST training in India

Is it a best practice that a post should have only one title? ;-)

Sharath Byregowda has won the Best Performer award at Mindtree. You know what it means to win the best performer award in an organization that has about 8000+ technical force. According to Mindtree there was a special guest who was invited to give away that award and that special person for them that day was me.

Sharath's manager, Murugan, wanted to make the award ceremony a very special one and surprised Sharath by bringing me in for the award ceremony. A manager so excited about giving away an award of Best Performer of the organization to his subordinate - made me feel wow. While traveling together to Mindtree office, I discovered that Murugan had a good diversity throughout his career and even tried doing business in the United States long ago with his friends. With all that experience, he thought, freedom plays a vital role in testing and hence provided it to Sharath who seeked it. India needs more Murugans. I think they have lot of Sharaths out there.

Freedom with responsibility made Sharath get him the award. This is the second time my student is getting an award at the organization level. Most of you might not know much about Shaham Yusuf but then he won awards for slogging important bugs and an unmatchable record of the highest number of important problems found in Deloitte India.

Testers & Blocks Consulting - Puzzle 2

You haven't yet read Testers & Blocks Consulting - Puzzle 1? You know Testerlock, right?


"Are you Testerlock of Testers & Blocks Consulting?" screamed a voice on the road just when Testerlock was buying some vegetables. Before Testerlock could respond, the young man filled with excitement said, "I have watched you test at a webinar and I loved the way you brought in so many heuristics to your testing approach. I even wrote an e-mail to you a couple of months back".

"And you are..."

"Oh, I am Philip. A senior tester at PepLabs and I really wish I could learn more from you. In fact my whole team would love to learn from you"

"I am glad you are interested at my testing as much as I will be interested to watch your team test"

"We have a problem though. Our manager somehow wouldn't get convinced that we need your training?"

"Really? Do you have some time, let me pay for these vegetables and we can sit around for a coffee"

"Oh, sure"


A few minutes later, Testerlock and Philip were at a Cup-O, a coffee bar in Portland, Oregon, discussing about the problem that Philip raised.



After the first sip of a coffee, "So, you think your manager is a barrier to bring me in, to coach your team?"

Approaches for interviewing in software testing - Book Kickoff & Launch of Interviews & Jobs portal

On September 1st, 2009, I decided to move away from my paying job to write this book - Approaches for interviewing in software testing. Before my bank sends an SMS "Lost your job?", I am hoping that I will finish this book and find a publisher. ( Also means: If you have any short assignments you can hire me or sponsor me for the book ). So, there you go. Now you know what I have been doing over the last 25 days.

A funny thing you should know - I had been writing another book over the last two years and then realized - writing a book is different from writing a blog or making a technical presentation at a conference. The kind of a book I was writing actually demanded a better writing skill from me that I dont possess right now. So, I have applied to be a participant at a workshop of how to write that kind of a book so that I better at least a little bit. ( let that remain a secret for a while )

Coming over to this book - you must first understand that this isn't just a book but something beyond the book. www.interviewsandjobs.com will serve as a platform to address all queries of testers related to jobs and interviews henceforth and also act as a flag bearer for the book I am writing. Santhosh Tuppad, my student at Practical Hands on Software Testing Training and a cool tester has been helping me a lot in the project.

I hope some of you will be willing to help in writing this book by contributing stories of your interview experience or other ways you will discover if you browse through www.interviewsandjobs.com

When you go to www.interviewsandjobs.com , don't miss out the teaser for the book. The teaser has the first 14 pages of the book and I hope it builds enough curiosity in you and your friends to ask for more and end up buying the book or sending the teaser to your friends through twitter, facebook, orkut or anywhere as you may like.

That's all, here. Go there and enjoy!

Bangalore Weekend Testers: Fun, Learn & Contribute

Let me brag a little bit and then get to the core. I don't believe in feedback forms that are asked to be filled by participants at the end of a training program. That's not a time to fill the feedback form because the value of the training can be determined only when participants get back to their work and apply the ideas they gained.

However, I ask all participants to fill it because the client who hired me wants it, so I don't necessarily change myself per se after looking at the feedback forms unless someone takes time to talk to me about it. As Mohan Panguluri says, "Pradeep, you are like Himesh Reshamaya. Either people fall in love with your music or they hate you at core" and its so true. My feedback forms hardly have an average rating. I am hoping that you saw this feedback report that I bet with all trainers of the world as hard to achieve. I either get a -30,000 rating or a 6 on a scale of 1 to 5. So, you see, how much they hate me?

Now, the actual feedback for me is when people go back and perform better at work. Of course you know about Sharath's great story that fetched him several awards at Mindtree. That's history now.

So, let's look at present. Quoting Jon Bach, "I prefer testers who are more curious than technical. Being technical does not make you more curious, but curiosity can make you more technical."

I mentor a few testers who are as curious or maybe even more curious than me. A co-incidence that these people also attended my workshops on Exploratory Testing and Rapid Software Testing. Among several good things they have done so far, I am starting to like their initiative of - Bangalore Weekend Testing


So, here is the deal of Bangalore Weekend Testing

They ( Ajay Balamurugadas , Manoj Nair, Parimala, Sharath Byregowda ) get together online, pick a product ( preferably open source ) and test together. At the end they publish a report that is helpful to the organization, team or open source project owners. Most important of all they have great fun and learn together.

I dont think you should be deprived of such fun and learning especially when it comes for free.

• It can happen from wherever you are and is a great way to have fun during weekend if you claim that testing is your passion.
• You will always have something to take back to your office on Monday and try out new things to help your organization.
• You would get to meet a lot of other testers online and network.
• You would learn from each other and better your ideas in testing.
• You could end up meeting them and doing more testing together.
• These people will also help you set up a blog and help you publish your experiences and could even mentor you.
• You help the community of software testers by demonstrating your skills and or through your reports.
• You help open source projects better their next release or plan for a next release.
  

Structure:

• Once you are subscribed to weekendtesting@gmail.com you will receive updates on time and projects that is planned for the weekend or it may happen as you find the registrants online
• A chat group is created on Gtalk by a facilitator ( say Ajay ) and invite all registered testers to it. ( Registration means sending an e-mail to weekendtesting@gmail.com saying "hey, I am curious" )
  
• With the help of a Session Tester, testing for a product would go on for about 2 - 3 hours or even more as the excitement goes on.
• Participants then spend time preparing their reports and share it across e-mail, get it reviewed and then publish it on their blogs ( if they want to ) or in a website that is coming up.
• Will be so much fun as you are in direct control of your tests. No manager or Lead watching you and no time pressure and no customer waiting for your report. Just do it!
• You wait for the next weekend.

Examples from the past:

Date:

01st August 2009.

Software:

www.vischeck.com

Testers:

Ajay, Parimala.

Blogs posts:

http://enjoytesting.blogspot.com/2009/08/paired-testing-at-distance-part-1.html

http://curioustester.blogspot.com/2009/08/paired-testing-at-distance-part-1.html

Reports:

http://www.scribd.com/doc/18007763/Testing-of-VischeckReport

http://www.scribd.com/doc/18008266/Experience-Report-for-Vischeck-1st-Aug-2009

----------------------------------------------------------------------------------------------

Date:

09th August 2009.

Software:

www.tinyurl.com

Testers:

Ajay, Manoj, Sharath.

Blogs posts:

http://enjoytesting.blogspot.com/2009/08/trio-testing-at-distance-part-1.html

http://testingredefined.blogspot.com/2009/08/here-comes-bwt-learn-test-and-have-fun.html

http://testtotester.blogspot.com/2009/08/weekend-testing.html

Reports:

http://www.scribd.com/doc/18321870/List-of-IssuesTesting-of-TinyURL

Note : These people are doing thing to bring the community together. It does not matter who you are, what certifications you have, what school you belong to, whether you like our ideas or hate them. All it matters here is - do you have the curiosity and passion to have fun through testing and yet be valuable to the open source community. Only fun and learning can unite us all - that's their motto.

Curious? Wanna have fun and learn to test better? Shoot an e-mail to weekendtesting@gmail.com

Join Facebook group of Bangalore Weekend Testers

or Test Republic group to get updates about it or to keep a tab on their reports and activities.

To all those who were concerned that community was constantly being divided, here is what could make us all one - fun while testing together. Here are the guys who are doing it. Be a part of it and have fun.

Update: Aug 18th, 2009

Check out how Bangalore Weekend Testers - 3 went and see if you are fine missing the 4th?

Parimala's Report : http://curioustester.blogspot.com/2009/08/bangalore-weekend-testing-3-bwt-3.html
Ajay's Report: http://enjoytesting.blogspot.com/2009/08/weekend-testing-session-report.html

Attractive professions and software testing

When I was a child I never dreamed to be a software tester and always wanted to be a fighter pilot, a naval commander, a cricket player, an astronaut, a doctor, aeronautical engineer, an actor, an army commando, a scientist.

Why didn't I think of being a software tester? Ah! Maybe because there wasn't anything I heard about software in 1980's but what about children today? They still say, "I want to be a pilot, a naval commander, a ramp model, a cricket player, a tennis player, an actor, a Formula1 driver, a Software Programmer, a Scientist"

I was investigating the history of how certain professions and sport are more popular and aspiring to many young people and discovered a few things about it.


Visibility: The idea of what a human does in a specific profession must be visible or made visible to a larger group of people who might not be in that field. For instance, my brother decided he'd want to be in army after he watched a movie "Border" and wanted to fight for the nation. In 1990, I watched "E.T." ( no, not Exploratory Testing but Extra Terrestrial ) and wanted to be an astronaut to be able to talk to aliens. A friend of mine watched Jurrasic Park and wanted to be a software programmer and a hacker. In parallel, I watched Kapil Dev's cricketing skills and wanted to be like him. Today my favorite sport is Table Tennis. Table Tennis has undergone a huge change in last few years to make the game more visible to the general public. Can you believe the ball size has been increased?

If you look at the Bolywood, you would see that one person inspired another to get into acting, music or direction. It was finally a movie ( Edison - The Man ) that changed my whole life downside up where I witnessed Thomas Edison's invention, hardship, work, experiments, challenges. I wanted to be an inventor and so am I, today, an inventor of tests.

Money & Richness: As a child, I didn't know the money behind each of these profession that I wanted to be in. When I discovered that cricketers are some of the richest people in India, I did dream a little bit about it and then the dream changed to movies, and then to something else that interested me at that time - complex electronic circuits. So, I did my Bachelors in Electronics and Instrumentation Engineering to help myself earn money being an Electronics Engineer. I am so close to electronics always, you see. When I am typing this, I realize a thin slice of key board separates me from a complex circuit. Being an independent consultant in software testing in India, I must admit I make more money than 98% of testers of my age or years of experience. Forget money, I feel, I am rich with testing knowledge and skills. I admit I am greedy to be more rich this way.

Parents: are a huge influencing factor. My father always talked about science to me. I used to ask him questions about science and engineering and he kept encouraging me in many ways by getting books on science or taking me to a science fiction movie. My mother was interested in Biology but I wasn't. I think my parents helped in fostering my curiosity. For a birthday gift at my age of 11, I got an Electronics - Make it Yourself kit from my parents that I assume as another key factor. So, testing suits me since it demands curiosity. In many countries, I do see the influence of parents on their children. The Bach Brothers ( James & Jon ) despite being software testers are also writers, like their father Richard Bach.

Community Respect & Relatives: plays an influential role for some people. I have heard during my relatives marriage and other social meeting about people boasting that their son or daugther got a job in IBM as a software programmer or a job with Microsoft at Redmond. So, hearing such words inspire other people to think of it so that they could boast about a similar thing later. They go back home and ask their children to aim for being a software programmer in IBM or Microsoft. Today my parents communicate proudly to their friends, "My son is a tester who is quite reputed for his work around the world." ( Ah! They do know about some of you who hate me and would not agree to that statement. )

Friends: often influence each other by introducing them to new professions that one might not have heard about. I still remember, a friend of mine who influenced me to be more serious about Electronics by showing a pocket radio that he had assembled. I wanted to do something like that and maybe even more. I quenched the thirst during my 3rd year at college by making the first telephone controlled gas stove knob with a circuit a size of Nokia Pocket communicator.

Mentors: During my first year at work, I worked with a tester who was trying to get on to the development team of the same project as he didnt like running test cases. I was influenced by him to learn programming and try my hands on programming. Although the organization who had hired me as a tester didn't want to take me as a programmer because they felt I was being useful to them as a tester, it helped me learn some bit of useful programming. I tried learning programming with the help of a System Architect and a Senior Programmer of the team, they helped me learn how equally challenging was testing activity by testing every program I wrote.

Professional Gurus: Oh! You know this. James Bach and Michael Bolton are my gurus. I have witnessed their testing online and have been constantly tested by them. They helped me clear the darkness I used to see in software testing and become a constant learner and practitioner.

Challenges & Fun: are something that everyone look forward to in any profession they want to be in. What most of the testers and people kept hearing about testing so far is - There is a process, we simply follow it. There is a test case, we simply follow it. There are those two things, we simply follow it. There is a tool we record and play everyday. There ain't any fun there ain't any challenge in following and merely recording and playing.

Exploratory Testing and Rapid Testing is gaining huge ground in places like India, ( ask me how many people are booked for my upcoming Exploratory Testing workshop and from where all they are coming and who are they ) software testing is becoming more fun, more challenging, and testers are constantly exploring lots of new things and discovering and inventing and more...


My analysis of Why Software Testing hasn't been that much of an attractive field so far?

• It lacked (past tense) visibility
• It lacked information about testers making money
  
• It lacked community respect
• It lacked parents awareness of the profession
  
• It lacked friends awareness of the profession
• It lacked good mentors
• It lacked enough professional gurus
• It lacked enough freedom being given to testers and hence wasnt challenging
  

My strong conviction of why the situation would drastically change:

Videos like this one which aids more visibility into our profession



and like this one which aids the curiosity of existing testers



and like this one that demonstrates the financial gain



and like this one that demonstrates the fun in being a /thinking/ tester as opposed to being a certified tester



And like this one that demonstrates the challenges

And like this one that demonstrates the exploration of new ideas to find bugs



While you are reading this, a child somewhere in the world might have opened Youtube and searched for E.T and hit this video and might be dreaming of becoming a software tester. I bet this is happening. I realize we haven't seen a father son tester combination but we have heard of Bach brothers.

Today is the foundation for tomorrow. What are we doing today?

Bangalore Workshop on Software Testing - BWST - 1

I interact with the Western world as much as I interact with the Eastern part. One of the things that the Western world does well that the Eastern part does not even do (significantly), is Peer Workshops. When I funded myself to be at CAST 08 conference, Toronto Workshop on Software Testing (TWST08 ) was a huge bonus for me. Thanks to Fiona Charles and Michael Bolton for allowing me to participate in it.

My first day at Toronto, Canada started in TWST08 even before I could get over the jet lag. I found that the Workshop was a great way to overcome jet lag. What I learned from TWST is still resonating in me and is of great help to my career.

I cant afford to fund myself to attend such peer workshops every year but I can definitely afford to participate in ones that happen in India. I tried to make testers meet happen in Bangalore when Michael Bolton was around here last time and it did not gain momentum after the first meet. I am forced to think that people turned up to hear Michael Bolton and they would turn up again when he's back. Prove me wrong.

Since then I was in a constant look out to meet people who would turn up for learning and I have found a couple of them. am also aware that there could be more people and that's why I am blogging about it.

There were lots of informal meets between Ajay, Manoj, Shrini, Rahul Verma, Vipul Kocher, Dhanashekaran, myself etc... and we did keep craving for more such things to happen. I think India cant afford to wait more to get started with Peer Workshops and this is an announcement for the same.

Mohan Panguluri, COO, of Edista Testing Institute who was awarded for his Thought Leadership in Software Testing in 2008 has opened up Edista's office premises for this Workshop. He has vowed to provide space to all future BWST workshops. Thanks a lot Mohan. You are setting a great example for other CXO's to follow.

Theme of BWST - 1 : Changing the way people test and think about testing
May 2nd, 2009

I believe that the first testing assignment that anyone did was handled pretty bad by them as compared to what they might be doing after a couple of years. However, growth stops at some point for many testers and only a handful make it to be real good testers. Those who turn out to be real good testers constantly kept changing themselves as they learnt new things and those who turn out to be bad were the ones who hardly changed. In India, we know, some of us struggle to change the environment around us to learn as much as we do.Similarly there are people who without much struggle get the environment around them to feel happy without any learning.

So, you could have changed your way of testing or others way of testing and you could have been resistant to change. Send in an ( one page ) abstract of your experience report that you wish to present at the first Bangalore Workshop on Software Testing by 18 April, 2009 and you will be informed if your talk is accepted for presentation. Failure stories are more inspirational than the success ones. I hope everyone has plenty of both sides.

The max limit is of 10 (maybe 15 if pressure builds) participants for the first BWST and hence if you plan to attend, remember that we work on First come First Serve basis. So, send in your abstracts of your experience report that you wish to present and keep in mind the theme when you do that.

Handbook : Please refer to LAWST Handbook and those that can apply to our context, will. We are flexible in changing things based on our first few Workshops.

Note: This isnt open to testers only from Bangalore. Anyone's welcome.

Also, you can start your own set of peer workshops in anywhere in India ( or anywhere in the world ) and no one is going to stop you. When you start, kindly let me know about it in advance so that I can plan to be there, learning from you all.

Email id to send in your abstracts: banwost [ at symbol ] gmail.com and we will have our own website soon. By May 19th, I will post an update on this and that's how we proceed. Are you going to remain silent? Are you going to change?

Change in hiring and interviewing process in India for software testing and software testers

I claim to be one of the most experienced and most affected tester in the context of interview in India and here ( in this link ) is more information about it. After going through that link or this video you would know that I have been struggling to not see another Pradeep Soundararajan in the job market who is frustrated with this industry's idea of interviewing. Edista Testing Institute ( my client and partner ) is constantly pushing towards seeing a better testing community and that's why I chose to work with them.

I consider the following as one of my biggest contribution to the change the industry needs. Most training institutes in India (even the so called highly reputed ones) have people who dont know to test, teaching testing by running a thousand slides. I think they have so many slides that if you run 25 slides a second to watch it like a movie, it still runs for about 2 hours. Such slides have always caused an avalanche slide of many victims career, knowledge and skills.

Edista started to redefine things by hiring me and then allowing me to hire Manoj and then Sharath and then now more people. The last I heard from Manoj is that testers who were interacting with him are now excited about what Manoj is doing and are enquiring what it takes to be able to get skilled in testing.

You might also discover that Manoj has started to publish his practice sessions on testing in his blog.

We sit to gether, test, learn from each other, create exercises, practice pair testing, discover new tools, debate on ideas, think about more heuristics, brainstorm test ideas, discuss about bugs, run a test club ( like the movie Fight Club ), teach people how to learn and then how to test. We are never away from testing and we are never away from anything about testing.

We aren't skeptical about the fact that there could be more people like us and who knows they might be interested to join us. So here goes the job posting for the same: ( and I have posted this in LinkedIn and other communities - please feel free to share this job posting to all other Indian testers )

Consultants in Software Testing and Software Test Education :: Bangalore

Profile:

Edista Testing Institute ( www.edistatesting.com ) has a couple of openings for Consultants in Software Testing and Test Education.

It wouldn't be wrong if I say, they are looking for people who have the urge to be heroes in software testing. This role demands you to train ( yourself and others ), collaborate with the on going research activities, test products, learn and innovate.

This role also demands you to grow to an extent to be able to contribute valuable things to the testing community and work for its betterment.

About your co-workers:

You would work with skilled testers and brains who constantly engage in learning activities, blogging, discussions, teaching, mentoring, challenge and argue online in testing forums ( like www.testrepublic.com ), offline and reinvent the art of reinventing things in testing.

If you think you wanted to be a hero ( or hero-in ) in software testing and never got the opportunity, here it is.

Eligibility:

We'd be glad if you have worked as a tester for a while ( at least 2 - 5 years ) and also be glad if you are willing to travel within India (or abroad ) on short term assignments.

We would prefer you have a degree in Engineering or Science however if you dont have them but have a demonstrated ability of good thinking, we'd be fine.

Interview Process:

Our interview process is cut above all other organizations that neighbor us. We put you in the testers seat, give you time to test a product and have a discussion of your testing based on the report you produce.

We aren't too bothered if you dont know the difference between Sanity testing and Smoke testing because we believe, knowing the difference ( even if it exists ) doesn't make a huge difference.

We aren't bothered if you have a certification in Software Testing or not as long as you are passionate, skilled in testing, and have the fire and fuel to take you a long way. In simpler words, it *doesn't matter* if you dont have ISTQB, ISEB or CSTE certifications.

About Edista:

www.edistatesting.com

Time to join:

Immediate is preferred. A little delay is fine if you are stuck somewhere.

Contact:

Send your profile to : resume@edistatesting.com

If you can crunch your profile in one page, we'd silently thank you for that.

The results so far:

• We invited about 7 candidates so far who claimed to have energy, passion and demonstrable testing skills.
  
• We are seeing great benefits of this approach.
  
• It makes us spend 3 minutes ( after a person has finished the test and generated a report ) to know about the claims a tester has made in his profile are fale and a little bit about the organization that said, "Yeah, he can test".
• We spoke only to one person in depth as his report was quite interesting.
• We know that we can filter more candidates with lesser time we have and get better ones to work with.
• It would be dangerous to get a person who cant test and report credibly into any organization that wants to hire testers.
• Those who fake testing experience fear to even apply or even if they do and by our overlooking we invite them for the testing session, we dont need to spend time beyond 3 minutes post their test.
  

Testers have to be tested on their testing skills and not on memorization skill. The best test ( based on the current situation ) you could give a tester during an interview is to make him sit on a computer and asking him to test a piece of software by giving a meaningful mission and time to do it.

Side note: Are you planning to be in the supporters list?

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. 

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. 

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.

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
  

If you are a tester and is interested to join a small test group 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. Write to me: pradeep.srajan@gmail.com