Conferences & Workshop update : Bangalore, Chennai & Pune

To those in Bangalore, Chennai and Pune, I am here doing some workshops and conferences.

Agile India 2012 - Bangalore : February 17 - 19

First, I am speaking at Agile India 2012. I am presenting a 90 minute workshop on Exploratory Testing the coming Sunday - 19th Feb 2012. There are about 750 registrations so far and this looks very exciting. Kudos to Naresh Jain for pulling things together. Moolya is a sponsor for Agile India 2012 but that is not why I got the speaking slot.

After having consulted for projects that claim to be Agile and seeing people fit scripted testing into a two week sprint, I really want to help them. I also want to help those who are doing exploratory testing, do it better. Am hoping Agile India 2012 would help me do that. Well, of course, I'd end up learning from the participants.

It is going to excited as I am going to be meeting a few people whom I met in Oredev 2011 as well as those with whom I interact online.

Invited talk - Bangalore : February 20 

I am invited by the senior management of a large company to present the Moolya way of testing. As of now, I can't name the company.

Corporate Workshop and Consulting : Pune :  February 23 - 25

My Dear Pune, you keep bringing me there often and I love you. This must be 12/13 workshop in Pune alone for a corporate client of Moolya. I would also be consulting a few teams to help them clear themselves of traps they may be getting into. It's so much Fun. Wanna catch up, drop me a note. 

BugDeBug 2012 - Chennai : March 24 - 25

I am doing a workshop and a talk. This is a conference I personally love because it is affordable for many testers. This is the third time I am invited to BugDeBug and I am probably the only speaker to have been invited all three times this conference has happened. This time it has a great line up of speakers. It has Vipul, Rahul Verma, Ashok T, and Anjan. More speakers to be announced on the website. One of the best line up according to me for India.

The sweet part is, at least half a dozen testers of Moolya are going to attend this conference and participate. Moolya is a silver sponsor for BugDeBug and again that is not why they gave me a speaking slot. 

So catch up with me in Chennai at BugDeBug. BTW, you know who else is doing workshop? Santhosh Tuppad & Rahul Verma on Security and Performance testing respectively. As I said earlier, it is great line up.

Register for my workshop here:  Limited Seats. and for Conference, here, I mean HERE

NDS (News Digital Service)  : Bangalore : March 29

I was recently a keynote speaker at Yahoo QE conference. It was great to have been there. I love the fact that among the goodies they gave, a plant was one of them. It is now growing well in Moolya office. Thank you Yahoo!

Some testers with whom I worked in the past during my employment who were now in Yahoo were surprised to see me as a keynote speaker at Yahoo conference. Apparently they were shocked but the great part was they appreciated what I had done rather than bringing in their ego. Fortunate to have worked with good heart people and unfortunate they didn't discover my blog for several years.

I am starting to call this talk., "The next generation tester" a legendary one :) Somehow, everybody wants this talk. I mock so much at the current generation testers (in as humorous as I can get) in this talk.

So, NDS is having a QC Fair and I am doing a keynote presentation to address their testing community of about 500 people in Bangalore. Fortunately, they have given me 2 hours time that I plan to make best use of to address problems that people may be facing to achieve their testing goals or question the goal itself :)

So, that's about speaking to at least 1000+ testers in a month. Why wouldn't my life be good? Catch up with me anywhere you are. Drop a note. Figure out my mail id. It is not that hard if you are reading my blog. Register for my Public workshop in Chennai. 

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!

Truth about test plan document & test case document

Not that you don't know.

Truth About Test Plan Documents

• 98% of test plan documents that are created are not updated, maintained or cared beyond sign off.
• The first 5 pages of a test plan document contains history that doesn't interest even those whose names are mentioned in it.
• Scope of testing section is the most funniest part of the whole document. Some times when testers report serious problems, some people cite it as out of scope. Hey, its still in the product.
• Customers worldwide could have saved millions of dollars if their vendors didn't care about creating test plan documents.
• 4 years into a project, nobody knows about the test plan document.
• No matter how stupid or intelligent the test plan document is, testers still write the test case they want to write.
• As an offshore services company, writing test plan documents are a cool way of billing customers without actually doing testing.
• Every stakeholder feels a false sense of achievement the moment they have a test plan document irrespective of whether they actually have a test plan.
• The cost of reviewing a document that nobody is going to use it is really high.
• Those who think they are not ready to test because the test plan document is not ready aren't testers by any means.
• A simple maintainable test plan document is far superior than a detailed test plan document.
• A mind map is worth a thousand good test plan documents.
• Test Plan Document is a Document, not necessarily a test plan.
• The next time you ask a tester to write a test plan where she knows it is not going to be used or maintained, she is not going to put her heart in it.
• Some test plan documents are written in a way that it is obsolete in its first draft itself.
• Some reviewers of test plan documents aim for perfection. More funny stuff, they may not even know what the product is supposed to do.
• Those who know about opportunity cost are likely to write a better test plan document.

Not that you don't know.

Truth About Test Case Documents

• ~ 90% of testers haven't bothered to think why there is a "case" in "test case".
• For most people on earth, a test case means a test idea that is documented.
• The expected results column in test case documents are a copy paste of requirements document / stories. So much money goes into re-writing the requirements document into expected results column.
• If you are already laughing at test case documentation, you may roar to a bigger laughter at trace ability matrix.
• Most traditional testing services projects have 50% of their project duration spent on writing test cases. The team members in such projects complain unavailability of time to "actually" test the product. No wonder.
• Unless the context demands, detailing a test case is a sin.
• Detailed steps in test case documentation provided for humans to execute is something I personally consider as an act against humanity.
• More than 99% ( yeah, more than 99%) testers I have met have passed a test case (or a bunch of them) without actually executing it. It is so f****** boring.
• Test case documents bring more money to countries like India than what Bill Gates must have invested in setting up an office in that country.
• Those testers who don't know to test without test case documentation aren't testers.
• More than 98% of projects I have consulted in India didn't have testers doing "test design". Here is a way: Take the requirement and write at least two or three tests to "check" if that requirement can be marked a Pass. That is all the design that happens.
• Test case documents are actually "Check case" documents.
• If there wasn't check case documents, software testing as an industry would have attracted more talent and helped in building more passion for the craft.
• Businessmen love test case documentation. Testers hate it. Businessmen hire testers to write documentation. Testers trade their time for money, end up writing documentation for money.
• Test case pass percentage is a great way to fool stakeholders. People love to be fooled.
• I personally can write test case documentation for any buggy product and make it look like a bug free product. 
• If all test case documents created so far were printed and burnt, we'd have fire for the next one thousand years.
• If you rate testers based on how many test cases they write per day, you'd always find people who can meet the number you want them to achieve.
• As someone said, "Testing at its best is, sampling". If you start writing and detailing the samples, you will have fewer samples than what you can have and you will never get to know about the product.
• If X test cases documentation takes Y hours, the amount of time spent on reviewing it and getting to sign off is 10Y. So, if X goes to 10X, we have 100Y hours of work spent on test case documentation.
• Some projects have great test case documents and no time to run them all.
• If you do a lot of documentation, you cant ship software, you can definitely ship documents.
• If you are hiring people who need detailed test scripts to test software, your hiring has ton of bugs in it.
• Those business people who ask testers to write "how long will this test case take to execute" and make estimations of test cycle complete time, should be executed.
• It is about Opportunity cost and Opportunity or Cost.
• No user has ever bought a product because the product was developed with lots of test case documentation.
• 99.999999999% of test case documentation I have seen so far doesn't care what the users really want.
• If testers read 1000000 words in a test case document the first time they were executing, they only read 10000 the next time and 1000 that next time and 100 for the next. Later, they don't need it.
• Some people think test plan document = test case document.
• The service most companies sell is test documentation, not testing.
• All good testers I have met so far, treat other testers as intelligent as they are and don't punish humans with detailed test scripts.
• Test cases don't assure repeatability of testing, at best it assures repeatability of testers getting bored.
• Funny that expected result of a test case should ideally be, "Software should go kaboom" BUT it is mostly, "We should see a boat sailing smooth as the day is bright and clear and the waters are not turbulent".

Just that, I know.

Trio Exploratory Testing - Session Notes & Discussions & The Big Dice

Oredev conference was super duper. The people I met and what I could learn from them was amazing. Siggie got a bunch of speakers for the test track and I was one of them. I met some context driven testers and good humans I was longing to meet. Selena was full of energy. Zeger was artful. Siggie has a cool style. I'd vote him for the next James Bond. After lot of talk (beer), talk (err, beer) and talk (and err beer) and little beer, the Kung Fu Panda in me said, "Enough talk, lets test". Update: How did I forget my country cousin, Henrik? OMG. He and I had enough beer one day that I need to recover from the hangover of our talk. What I am attempting to do with Moolya is what he is trying with House of Test. Another update: Another beer made me forget my dear friend Ola Hylten. He took me home and it was made this as one of the nicest trip ever. Miss him.

I got hold of Rikard Edgren and Shmuel Gershon and we decided to do an exploratory testing session. Here is what we did.

Click on the image to enlarge

All three of us enjoyed doing this so much that we hope we can do more of this in all future conferences we meet. What was more interesting was the de-brief and discussions that followed. After we finished testing, Rikard said, "Oh my, you write a lot of notes. I would spend that time to find more issues". That is brilliant but I explained to him about why I do it. It helps me tell a story of how I did things even years later. I pulled a test session I did 6 months back and narrated a story of how the session went. I then mentioned that my style of note taking could be useful in situations of high accountability.

Oh, our Rapid Reporter Shmuel was there. We talked about Rapid Reporter and its use in Session Based Test Management. Shmuel brought shared with us a feedback  : A tester doing scripted testing and using Rapid Reporter found that he was taking notes and found it very useful that he could learn a lot. He said he started making notes of things he used to miss in the past without it.

Rikard shared stories of his testing style. His style appeared to be like one where he didn't want documentation to act as a hindrance to the progress he wanted to make in finding bugs. Well, I think he is right. It shouldn't. For those who have seen how I test, I do the notes part so quick that it doesn't compromise the goal I want to achieve. I felt I was defending my style too much. Yeah, to an extent but then hey it is my style.

We then started to talk about how each one of us adopted SBTM what James and Jon had provided long ago. I talked about how I tried doing it with the style I have seen James doing and how I failed :) It also meant lot of questions from James that I could not answer. The only way I could answer to his questions is to adopt SBTM to my style of testing.

We had an interesting interruptions in between. Some people were constantly checking with us what we are up to. One of us took the job of engaging them in a conversation while other two continued the discussion.

It was one of my nicest experiences to have tested along as good testers as Rikard and Shmuel. I simply love them and am a fan of their work. My sleep is interrupted with the potato and rapid reporter :P. Fortunate for me, I use Black Viper Testing Technique to solve many problems.

Shmuel has come out with idea of BIG EXPLORATORY TESTING DICE inspired by Rapid Software Testing Heuristics and I think this is one of the coolest contributions from Shmuel other than his Rapid Reporter. I have a pair of them on my desk.

 Oh you too see the Cartoon Tester in the background? Hate this guy, he is everywhere in Moolya :)

How to use it? Here is the tutorial : Roll the dice and read what is written on it. Ask yourselves if you have asked questions about what you read. For instance, I roll the dice and see "Support-ability". It reminds me to ask questions about what kind of support-ability is built into the system I am testing. How could someone recover logs from crash? How will the support staff know what the user has done? How will the user know how to explain what happened? So cool.

If I have missed anything interesting, I am hoping Shmuel and Rikard can't resist themselves to add their comments on this post.

Gifting someone a life and they f****** it up

Oh my! I was reminded of this story. It is a hard to digest story for me but I can't just hold myself from telling it.

About two years back, I did work for a client in India and they had to pay me about a couple of thousand dollars. Meanwhile, a fresh college graduate who was trained by some testing institute came to me seeking help in getting a job. He convinced me that I should help him. I was emotionally touched by the way his parents struggled to help him complete his engineering bachelor degree course.

His parents were daily wage farmers in some village in Andhra Pradesh. His parents were getting paid something like 3 to 4 dollars per day and they used to save as much as they could in that money to help this guy study.

He also seemed to express interest in doing some creative style testing and thinking. Convinced that this guy needs an uplift in life, I called up my client and said, "The money you were wanting to pay me is important to me. It would make a small difference to my current life style but God has helped me be happy with what I have right now so I need to ask a favor from you. I know this guy, XXXXX , who needs a job to help his family in basic shape. So if you could give him a job and pay him what you owe me, I'd be more than happy to engage with you again"

The client was very open to the idea but checked with me that I am not making up my mind to gift him life because it comes at a cost. I thought I knew how much it would cost.

With a couple of thousand dollars, you could buy lots of things or be happy having it in bank. My wife and parents were proud of what I did. This guy thanked me for gifting him a great opportunity. I told him that he is being given an opportunity with his parents in mind and he needs to work really hard and learn to do very good testing. He nodded like a doll.

I was constantly checking with my client of this fella's progress. The client said he was good and I was happy that he was doing good. A couple of months later when I tried to check again  I found that this guy had not been performing as good as he used to be. He seemed to be enjoying his life more than learning and improving skills. I wrote to him about it but the response didn't seem to suggest to me that he was serious. We then watched him for a couple more days and I called up my client to ask them to fire him because they didn't do it thinking I'd be offended.

He was fired. He lamented about his mistakes over a call with me but it was too late. I lost my money and possibly the reputation I had built with this client. Its sad that I lost money and faith about people asking my help. It reminded me of the stories I read in Panchathanthra. They are so true even after 5000 years.

Well, it helps me become wiser but makes me nervous to help somebody who brings up the emotional angle. Decisions in life are always based on emotions or the lack of it and they are heuristics.

I am not telling all I have helped have done this to me but even if one does, it creates an imbalance to the way I was dealing about helping people. Passion to foster good testing and good testers continue to guide me take decisions like the one above. I hope I have enough strength and money to pursue my goals despite such cases. You never know how much your decisions are going to cost you. I am not pained at having lost couple of thousand dollars but feel sorry for that guy's parents. The last I heard from that guy, he still wasn't able to find another job. 

Reminds me that sometimes opportunity knocks only once. Other times, we have to create it. If we aren't skilled, there is no way we can create opportunities.

Amen!

TASTRO - Tester's Astrology by Rrajesh Barde

One of Moolya's customer, a large IT company in India wanted me help a group of testers think beyond the boundaries they had accustomed to. They wanted me to help them bring out the potential and creativity of testers within their organization. Having thousands of testers,  they did know where to start from - the top 30 they had. Top 30 in terms of demonstrated passion for software testing.

The icing on the cake, they wanted their testers to progress towards becoming brainual testers.

A group of 30 testers were introduced to me and I spent time for a couple of weeks with them on various activities. We ended up doing so many good things together that we accomplished the mission together. There were plenty of great work that they did. Now, those 30 have been successful in inspiring 30 more and this chain reaction is appearing to happen. If it goes on, I am sure this organization is going to rock in the coming years.

Somebody impressed with how I mentored these 30 asked me, "Aren't you giving away all secrets of how testers in Moolya test?", to which I replied, "There is no secret. This is how we test and this is how we live". There is nothing to hide. We don't have any secret ingredient or a secret ingredient soup unlike many services companies. We have watched KungFu Panda and hope you too have watched it. We focus on our skills. Our website tells that story.

In this post, I want to highlight the creativity that came out of the exercises of Brainual Testing.
Rrajesh Barde surprised me that he had been reading my blogs ever since I started it and he told me he had also commented on it. I was glad to meet my oldest (well, he's pretty young) blog reader. The only question I asked him was, "Was it worth your time?"

This guy turned out to be hyper creative. He had a sense of humor, lateral thinking, passion to test, leadership and creativity. We were brainstorming of how do we educate testers without letting them know they are educated. Of course, books are boring to most. What content do we feed them with? We discussed on Andy Glover's Cartoons for it. However, that didn't solve the problem of testers within their organization being able to see Andy working with them.

So, Rrajesh Barde in the meeting interrupted, "If I may, I have an idea..." and then came out with this brilliant idea of TASTRO - Testers ASTROlogy. In a country like India, a lot of people refer to Astrology. They at least want to read if there is something good in it for them. I thought that was a brilliant idea and we had to develop it further. We needed to mix fun and pun into it. We needed the learning touch. We needed people to look forward to their weekly TASTRO.

Here is what we got:

TASTRO – Tester’s Astro – What do your test signs foretell?

Aries		Your stars look good for coming week however you might face an environment downtime. Why not make a quick checklist on how to set it up?
Taurus		Avoid calls during Rahu Kaal. Those who have calls with your on-site coordinators during this time, Beware!!
Gemini		The planetary movements suggest that the build scheduled on week day will be delivered to the Testing team on Friday after sunset. You have plenty of time to read Rapid Software Testing Appendix and practice new testing ideas.
Cancer		Though you think you know it, you have no certainty until you try. You might see a surprise appreciation for your smart work. Smart work could mean, you use oracles to test.
Leo		You are worried with unplanned work load. Read the book – Lessons Learned in Software Testing at home and you may see the change in office.
Virgo		Worried why you your productivity appears to have come down? How long has it been since you took a break? Quick breaks between test sessions are important.
Libra		In the busy times, be prepared to work late, eat pizza for dinner at work, and work for some weekends. Don't wanna do that? Go beyond test cases, you will find more bugs.
Scorpio		There is a chance that your relationship with developers would go sour in the coming week. So treat them with chocolates. Developers are rich source of information for a tester.
Sagittarius		Your customers would be under the influence of aggressive Mars. You would be forced to test whatever is thrown at you. Check for the mission to be achieved to avoid falling into traps
Capricorn		You would be trying to achieve the stars by clicking here and there with your monkey paws. Stop doing that and your career could get better.
Aquarius		Your managers would somehow have a strong notion that you have just been marking those test cases as “pass” without executing them. Honesty is important for a good tester.
Pisces		When you have crashed the software and waiting for the system to boot, prepare your own test idea cheat sheet. For those who do, future has been bright.

Isn't this awesome? I feel testers like Rrajesh Barde are a huge boon to our industry. The beauty of my consulting was, I felt there wasn't just one Rrajesh Barde I met but many. I may cover about others in future posts.

A couple of years ago, I used to go to a consulting assignment as though I am superior and I consult people because they were inferior. These days, I go to consulting to get humbled by people like the ones I met.

Please, everybody, stretch out your creativity, you would find an Andy Glover or Rrajesh Barde in you. For those who want to follow Rrajesh's blog, here is the link. He came out with another concept called Bug Burji (Burji is a dish made out of Egg and we call it Egg Burji, Rrajesh made a Bug Burji out of it). Rrajesh, you inspire me. I hope after reading your work, a couple of others may join me in admiring your work and contribution.

I am telling myself that I was born to witness this beginning of the golden era of software testing. Don't know if you can even see what I am experiencing.

Testing Circus, Tea Time With Testers & The Testing Planet magazines

It is a proud moment that a magazine on testing started by a tester in India who did not have any funding or money to run it has completed 1 year and has matured well over the last couple of months.

It is testers like Ajoy and his team of volunteers listed here are the ones who are going to make a difference to this world in all good ways. It re-iterates a good point that passion can make things and sustain it. Many with huge budget but no passion can't achieve this. Even if they achieve, it may be with just business objective.

I want to congratulate Ajoy and his team for the efforts they have taken to bring this magazine out every month. Ajoy wanted to have enough money to run this and Moolya was the first company to sponsor ads in Testing Circus.

It wasn't just to promote Moolya but to help Ajoy and his team dream bigger with Testing Circus. To all those involved, I bow to you, salute you for what you have done. I know, probably more than anyone else, how difficult it is to have achieved it.

So, this post is dedicated to you folks.

There is another set of testers from India, Lalitkumar Bhamare and Pratikkumar Patel who are also doing a good job. They are the Tea Time With Testers. I want to mention and thank them for their efforts. I sincerely appreciate your work, passion and style.

Now, to both these magazines, your goal over the next couple of years is to be better than The Testing Planet. That appears to me as a golden standard for testing magazines to achieve. Rosie Sherry and her team of volunteers have not just set but raised the standard too high for others to try beating. I still remember the day when Rosie Sherry started the software testing club and pinged me on Skype to tell about it. I think Rosie should write a book on how she built all this so well.

All in all, this is becoming a good age to live in as a software tester. Those who are blind to all great work happening in testing deserve it because their children or grand children are probably not going to respect them :)

Subscribe to these magazines and you will thank me for asking you to do it. 

How Pradeep teaches software testing - Part 3

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

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

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

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

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

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

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

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

I am listing a few of them below

Skills

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

Technical

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

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

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

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

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

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

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

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

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

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

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

How Pradeep teaches software testing - Part 2

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

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

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

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

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

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

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

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

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

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

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

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