Collection of Notes & Experiences: Bangalore Workshop on Software Testing 1

Approved for Publication by all Participants

Theme: Changing the way people test and think about testing
May 2^nd, 2009
Venue Sponsor: Edista Testing Institute & Test Republic


Participants displaying their K - cards
For more pics, click here

Participants ( not in the o: Ajay Balamurugadas, Aishwarya D Shukla, Guruprasad, Manjunath, Rahul Verma, Rahul Mirakhur, Shrini Kulkarni, Manoj Nair, Ravisurya, Santhosh Tuppad, Shikhar Singh, Raghu Sahay, Sharath Byregowda and Pradeep Soundararajan

Bangalore Workshop on Software Testing officially started with the announcement on my blog on April 12, 2009. We had about 15 people rushing in their registration and abstracts for presentation. When you see the list above, you would know who finally made it.

We tried following the LAWST style peer conference and we think we did. I played the role of host and facilitator. I am sure the next time someone else will play the facilitation. I learned facilitation by observing Paul Holland do it in TWST and CAST. He is an amazing tester and facilitator. We used K-cards and that really worked. You would see in photograph, people holding K cards.

We had a check in and introduction (as there were a few faces who did not know each other) at 9:30 AM followed by Ajay kicking off the first presentation.

Ajay’s presentation: Rapid Software Testing

Ajay talked about the change he had after attending my workshop on Exploratory Testing – A Rapid Software Testing Approach and how it helped him log several hundreds of bugs when he started doing a structured exploratory testing. He explained how he struggled with the templates that he had to adhere and how those test cases filled in templates failed to yield coverage and value.

Ajay brought in an interesting thing: “When I started to log more bugs, people were skeptical of how I was doing it. They used to think I was stocking them and releasing it as required”. In this case, Ajay funded himself for the training.

It surprises me that some organizations get their resources trained to help changes to occur to their work and grow skeptical when they get to witness the change.

Before he finished his presentation, he mentioned how the management started seeing Ajay’s work output as a different value than what they expected out of him. What they expected from Ajay was to run as many test cases as possible and what he ended up producing was finding defects and reporting them in their bug tracking system. That is an interesting one – test cases are there, wherever they are, to help testers find bugs and some managers might be misusing it to show progress of testing. I have heard it happens everywhere in the world and not just in India.

During the facilitated discussion that happened after Ajay’s presentation, Shrini mentioned, “The value depends on what stakeholders defines it as”. However, sometimes some stakeholders might need education from a tester to have more meaningful value definition.

Rahul Mirakhur (RM) brought in the idea of a tester wearing different hats and being able to think the value that different stakeholders might want from a tester.

When he interacted with Support teams in an earlier organization, it opened up a completely new world of information source and that, changed the way he did testing thereafter. It also gave a glimpse on how different functions on a project bring in value and in the case of Support teams case, value is more "after" product release.

As the discussion drifted to bugs, Rahul Verma said, “I see bugs as questions we can ask”

Manoj Nair’s presentation on An attempt for better testing

Manoj talked about the opportunity he got in his project where time crunch and amount of testing to be done, enabled his manager to bestow him with a freedom to do free style exploratory testing (without much documentation) for an important feature in his project. The defects and the information he came up by performing free style exploratory testing made the management to postpone the release realizing the danger. He felt happy with his effort, until he was required to explain the details of test coverage across the feature and provide test case document for the tests he conducted for those features. The test case document he prepared were subset of the entire range of tests he performed because he did not have time to document all those tests. He realized the value of tests he did could possibly diminish through that activity. Looking back at it he felt, if he had used Session Based Test Management, he could had done a much better job in providing test ideas document.

During the discussion, I talked about the idea of a Wiki for changes to the product open to all team members and the value it could have for the test team.

Aishwarya, an undergraduate student asked a striking question, “How much information would be an overflow of information?”

The discussion then digressed to – When is the right time to get testers on the project for which all participants had different ideas and experiences. Many organizations have tried bringing in testers early and late and most of them are not yet sure when to bring them in.

I argued that it depends on the kind of a tester an organization is trying to bring in and other factors. Not all testers are the same. I have witnessed organizations that actively ignore testers in requirements review meeting as they have had a bad experience of bringing in a tester. It makes me think that if I lose credibility, it affects other team members in my test group. That is how important it is for each team member to have and build credibility.

Manjunath’s Presentation of Review of Review of Review of Bug Reports

He talked about his experience in one of his previous organization in the context of bug report reviews conducted to help testers log better and credible bug reports. This exercise was undertaken based on the success of improved bug report quality, post a review of each bug reported from the previous project.

Interestingly, in the second project there was another level of review that happened over the review comments of bug reports. The tester, whose bug reports were review had an option to appeal for escalation if he found the review comments did not fit his (her) bug report. It got many testers to defend each of the review comment of the bug reports they logged. Thus spending more time on a single bug report, instead of finding more bugs. That's opportunity cost. That’s like review of review of reviewed bug reports. Yes, we did have a good laugh!

This process was then declared a failure for the second project as its implementation went wrong and 
ceased to exist thereafter, maybe. 

The process can become so worse that it might eat so much time for so little value. On probing, Manjunath revealed that the review process was actually initiated to help testers write better bug reports. All participants were convinced that the way in which the mission was executed might have been poor and what works in one context does not fit another. I am sure we are going to remember Review of Review of Review of Bug Reports experience report.

Doesn’t it help us understand that the best practices do not work for another project within the same organization because the context keeps changing?

During the discussion, we discussed ways of credible bug reporting and shared our experiences of reporting bugs through Video recording of the bug and the value it has had for people who experimented that. It cuts across communication barriers and I am surprised why this practice is not widely used. Oh! 

Someone hasn't talked about it as "best practice" yet? It then digressed to how much English should testers know and then RM talked about practicing English as a daily activity as opposed to a one time upgrade of English skills.

He provided inferences that it’s (relatively) harder to learn language (or command over it) when we get old compared to when we are young. Shrini mentioned that it is not a "rule" by citing his personal experience of how despite being relatively old (compared to most of the audience), he is constantly on the lookout to learn new things.

We got back to reviewing and then discussed on reviewing as a skill and review effectiveness.

Lunch Time folks!

At about 1:15 PM, we walked to a nearby hotel down the street and carried over facilitation-less discussions over lunch table. A heavy lunch

Then when we returned, something helped us get the heat back… Rahul Verma’s presentation on Confessions of a Fallible Tester

This was a very energetic presentation we had for that day and thanks to Rahul Verma, he did it right at the time it was needed ( post lunch )

He made confessions of the mistakes he did right from the start of the career where he thought testing was not his cup of tea. He just did not confess but also explained how he learned from those mistakes and lived better after each big mistake.

One of his confession sounded very cool - “When senior testers in the team said XXXX XXXXXX was the best tool, I believed it” and then he explained how the project suffered because of that tool or the idea of thinking that as THE BEST Tool.

He explained how he cleared that trap and ended up writing a customized plug in to work with XXXX XXXXXX to make it suitable for his testing context.

He then confessed on another mistake of how two blank lines that caused the test environment to fail to enable the product to be tested over it. He or his team members make turned the case by defocusing the customer to something else when the customer observed it. The message was – Test your Test Environment. I think those who do that today are the ones who have realized the value of it. Many testers just setup and start running their test cases without bothering if test environment is what they intended it to be.

The discussion kicked off and we started discussing about tools. The topics varied from Automation Readiness to Vendors bribing managers to sell their tools to Good code versus Measurable Code.

From Rahul Verma to Rahul Mirakhur’s presentation on My career and experiences in testing

He started with a cool question, "When people say WHY will you want to be a software tester, I ask WHY NOT" and I think that was exciting. RM had some interesting observations about IT people in India – “By the time people realize what they are good at they would be in some other domain and would have beefed up living a luxurious life that doesn’t allow them to shift to something they want to do”

He asked another question “Anyone can be trained on software BUT what can they really do?” and discussed that every human is a born explorer and testing is an innate thing and can be developed by proper training.

He then talked about his experience of witnessing developers who moved to testing because they were interested in testing. He then said based on his experience, “Jump into development first if you are serious about becoming a tester”. He shared the experience and value of hiring a person who earlier worked in a support job.

The discussion post this presentation helped in understanding how many different ways are there to get into testing and the value of taking each way. We also talked about the value of learning testing from other fields and that reminded me of CAST2008 conference theme and presentations from there.

RM went back from BWST and started a blog and has promised to keep posting. Another credible blog from an Indian tester on the way - check out.

Sharath Byregowda’s experience of Session Based Test Management

Sharath talked about his experience of experimenting SBTM on the project he worked for and how he influenced other testers, the management and customers with it. He has detailed it in his blog post and I am sure you'd read go there and read it or maybe even learn from it. His team won an award for achieving great results in his organization that has thousands of testers. In addition, Sharath got another award from Michael Bolton.

We had an interesting comment that - By the time an organization implements some new practice as a "best practice" and penetrate every team, the idea is outdated. It reminded me of Ted Neward’s presentation at Oredev08 where he talks about the time difference of programming language birth to becoming an industry usage.

Shrini Kulkarni’s experience of test automation consulting

Shrini talked about his experience of becoming a tester and then about how he grew from being a fresher in software testing to wherever he currently is. He then talked about an interesting experience of Test Automation Readiness Assessment that he was supposed to do for a client in North America and the challenges he had. Shrini talked about his confidence in doing it although his colleagues thought of it as an impossible task. Shrini detailed the value of collaborating with people like Michael Bolton, James Bach, Cem Kaner and others that have helped him evolve to a Test Automation Expert.

 Shrini also talked about his consulting experience and mentioned that almost all test consulting assignments he witnessed, the client was interested in knowing some "universal" or industry standard benchmark related to testing - be it dev to test ratio or % of project cost that could be associated to testing. His experience was that he rarely witnessed anyone challenging those industry standards. In his opinion - That is hindrance for our profession.

Discussions on Test Automation, mindset and skill set followed Shrini’s presentation until the bell rang at 5:30 PM

We had a quick check out and got on to the socializing evening and facilitation-less discussions. We decided on a Food Court in Koramangala and spent about 3 hours there munching food and discussions on Cricket, Movies, Testing, Food, Beer and Wine.

What a fantastic learning to all of us. I must thank Shikhar Singh and Raghu Sahay for coming down from Mumbai and Pune to attend BWST-1. It was fantastic to note that Aishwarya Shukla, an undergraduate student, wanting to do a software testing project as his final year project after attending BWST along with Santhosh Tuppad who completed Practical Software Testing Training at Edista and has been working on several testing assignments as a freelancer. Every participant asked questions that helped other people learn and discover more about themselves and the work they do.

Once again, special thanks to Mohan Panguluri, Pradeep Chennavajhula and Rachna for providing us the space @ Edista Testing. I wish India has more leaders like them who facilitate knowledge sharing and learning in software testing without just being business minded.

Shikhar went back to Mumbai and wrote an e-mail to me regarding Mumbai Workshop on Software Testing that he is planning. Watch out India!

Here is the list of Post It Notes that all participants contributed as an additional reference points to the discussions we had:

• Only testers can talk about Testability
• Book suggestion: Perfect Software and other Illusions about Testing – Jerry Weinberg
• “Every bug is a duplicate of a master bug that the product fails to do something that is important to work for someone” – if that sounds bad - that's still me.
• Philosophy in Golf & Testing – Adam Goucher
• Bug Advocacy – Cem Kaner
• How to investigate Intermittent Problems – James Bach blog post
• “The best tester is the one who gets the most the right bugs fixed” – Cem Kaner in Bug Advocacy
• Do confess when you screw up
• Turning Numbers into Knowledge – A book by Jonathan Koomey
• Lessons Learned in Software Testing – Kaner, Bach, Pettichord
• “Automation could be a dangerous word for a tester” – Rahul Verma
• “If you have failed big, it indicates you rose to a great height” – Rahul Verma
• Value of Checklists – Cem Kaner’s presentation in CAST 08
• Video Record Your Bugs
• The intake I have had from BWST-1, has questioned what I have learned so far. It has helped me to unlearn and learn consistently - Ravisurya
  
• "When I spoke to support teams, it changed the way I tested, forever" - Rahul Mirakhur “
• After I attended Rapid Software Testing Workshop, my testing improved” – Ajay Balamurugadas
• “The value you add as a tester is like NAV of an investment. It changes every day” – Shrini
• General Systems Thinking – A book by Jerry Weinberg

Video : Against Best Practices in Software Testing :: Oredev 08

Here is my talk at one of the coolest conferences: Oredev, Malmo, Sweden, November 2008.

Great* testing stories from India
( Created by *not* following any best practices )

Highlights of the talk :

• I was fired from Motorola trying to follow James Bach's advice
  
• Test cases make people mad and sad.
  
• Sharing 230 stories in 45 minutes.
• The value of doing things that that context demands.
• Questioning things that happens in India.
• Truth of how many organizations get CMMi and ISO certifications.
• Independence day for software testers
• Brain is also a tool used in software testing, consider recognizing it.
  

Blogs about the talk so far:

• The test Eye - Notes from Oredev
• James Bach - What Impressed me at Oredev
• Sogeti Blog - Oredev 2008
• Ola Hylten - A blog about testing

I thought of making the video private instead of public and wrote to Michael Tiberg and he pointed out that this talk had received high rating from the audience and that I nailed some important points. I then decided to let it continue to be in public mode. I hope you'd enjoy the talk. Thanks to Michael Tiberg and Emily Holweck for putting up a great conference.

Oh you should watch James Bach's power packed keynote on Renaissance in Software Testing at Oredev. It left me crying for a couple of minutes.

Checkmate heuristic :: A security testing attack

It has been five times over the last six months that someone considered hiring me before making a release decision or after getting skeptical about scripted tests.

Amidst recessionary times, someone considered outsourcing some testing work to me from United States. An advanced version of the product was slated for a release in the next couple of days. The United States company had outsourced development and testing work to a Structured Fancy Name Process Following Disciples company who had ran through thousands of tests over it and had achieved >98% test case pass, a week before today.

Someone in the United States company thought they'd like some Exploratory Testing and I got the opportunity to lay my hands on it to perform a Rapid Testing on it. The charter for me was to report any security related threats and usability problems.

I found about 14 potential problems in about 5 hours. On the 6th hour I found 2 more security problems:

• I could reset the password of any account by tweaking the variables that the client was using to interact with the server.

• I could stop auto e-mailers reaching any registered mail account in a similar manner as above.
  

I then tried to reset the password of the dummy account I was using. No e-mail reached me. I then thought, "How about reset of admin account?" and then did the same.

The password was reset and no e-mail reached the admin, as auto e-mailers were stopped. So, I asked the admin of the UnitedStates company to login from his credentials and the response was a pleasent, "What did you do and How did you do that?"

Subsequently, all other users were blocked. Only the admin could release the lock but the admin could not log in to the system. 2 hours of outage till someone got into the database to recover the admin account.

You write a lengthy email, hit the submit button and the application prompts for your Username and Password. You enter them and it says, "Incorrect Username or Password". You attempt to reset your own password but the email does not reach you.

Checkmate!

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?

Excerpts from participants work - Practical Hands on Software Testing Training

• Are you curious to look at excerpts of the participants work that we have been consistent in achieving from Hands on Testing Training that I talked about in 2008?
• Are you aware of the power of young generation?
• Are you aware of the power of coaching them with better education in software testing?
• Are you aware of the impact of providing better education in software testing to young generation today is going to be one of the key factors of deciding the future state of software testing?
• Are you aware you can read more about this?

Read more... and write to us ( isupport [//at//] etifinishingschool.com ) know if you'd like to support this initiative.

Audio Podcast :: What Software Testing Could Be?

If you haven't noticed that I have been doing audio [and video] podcast series Testing Stories from India, no problem. You have known it now.

Here is my latest podcast: What Software Testing Could Be? [ 3.18 MB ]


Summary:

• There could be about 28,000 definitions of software testing
• What? Are there rules of software testing?
• Many testers don't test their own definitions of software testing?
• Certified testers hardly speak about the definition they learnt to get certified.
  
• What is Pradeep Soundararajan's definition of software testing?
• What tests did I do on the definitions I subscribe to?
• What is your definition of software testing?
• Have you tested the definitions you subscribe to?

Previous Podcasts:

• The word "TEST"
• Test Plans Aren't Ice creams
• Testing Lessons from Beer
• Indian Testers and Fake Experience

Software Testing Videos:

• http://www.viddler.com/explore/testertested

If you can't download these because your organization firewall doesn't appear to have bugs that let you download these, write to me, I shall send you a copy in an e-mail.

Karnataka state missing from official Indian government website

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