tested a new conference in India for software testers #tested

Isn't it so awesome that we announce a conference 3 weeks before it is going to happen? We made http://test-ed.in live just couple of hours ago and announced the new conference for software testers in India. We made all background work much before we did the announcement. The venue, speakers, event organizing, badge-tags for 600 people and much more secret stuff.

However, what we don't yet know is if we can get 600 people in 3 weeks. The pricing is definitely something that people can afford. I went back to starting fresh out of college and asked if I could afford it then and when the answer was yes, is when we moved ahead with the pricing of INR 500 or USD 9. A full day conference with world class style for USD 9, can you believe that?

Moolya can make it happen. The program is designed in such a way that there is enough time for the audience to contribute and question people like James, Rahul and others. We have a dedicated one hour open season for people to ask questions and topics close to their heart or what is burning them down. With a collective 600 brains, we believe we would get a better understanding of how we can help someone solve the problem.

I have been to great conferences (like Oredev) and pathetic conferences whose names are not worth mentioning. So, I'd like to aim for being Oredev but I know there is lot more we need to do to get there. However, I don't need to be Oredev, I need to be test-ed. This conference will have plenty of things that makes coming to this conference beneficial to the community.

We are going to gather test ideas from the 600 people who are going to attend this conference (look at the confidence in me, 600 people in 3 weeks) and are going to collate and open source them.

James Bach is going to be doing this awesome talk on I serve by doubting - the rise of the Indian thinking tester. I bet, James has not done this talk ever before and it is going to be awesome. For a lot of people wanting to meet James Bach, this will be a great experience. He is going to talk for 2 hours + be available during the open season where people can ask any question to James, me or other panelist.

For some testers, some cool ones, we are going to give away James Bach autographed (signed) Lessons Learned in Software Testing books or if people are bringing their own Buccaneer Scholar books, they could get it signed by James Bach.

Rahul Verma is an awesome presenter. His background is theater and he is a performing artist when he speaks about testing and his experiences. We know that every person who has heard of Rahul Verma is going to register.

Then comes me, the super hero :P (well, did you read it super-ego?). I am going to be talking how I know I am a good tester and what fists I use when testing that most others don't.

The Indian testers are slowly being recognized worldwide. This is important for Indian IT and Indian Testing services industry to grow more reputable and credible. We want to celebrate that and help more testers to do better. Moolya is one such company that can make it happen. Welcome to test-ed. Your own! Now, read through the awesome website and if you like every bit of the website, give your kudos to Mohan Panguluri, CEO, Moolya who was the sole person who weaved this site to give so much life to it. Tweet, Instagram, Linkedin, Facebook with hashtag : #tested

test-ed
Register and spread the word.

James Bach Live in India : Hosted by Moolya : December 2012

As James Bach's student and colleague, it is such a proud moment to build a company that within its 2nd year anniversary is able to hire him to help us and fellow Indians be more inspired and challenged.

A lot has changed since James came in 2003 to India. James is definitely more excited to come to India now. He sees there is a lot of potential here, a lot more than what he probably thought existed in 2003. It is not because of me, it is because of you folks. A company is beyond an individual. The stories that James has listened to and experienced over the last  few years about testers in India has convinced him that this is a region of the world to look out that could become a serious competition for value and not just on cost to other countries of the world. About Moolya, too. He was recently in Finland and someone recommended Moolya to him as a good testing services company.

James has published this on his website "India has a lot of testers, almost all of whom are unknown to the Context-Driven School of testing. In recent years, leaders have been emerging. And this is a very exciting development."

There are more and more testers from India gaining international reputation and demonstrating the value they can add and on how par they can think with great thinkers of the testing world. We as Moolya wanted to help more testers from India gain the benefit of James expertise. 

A lot of Indian testers are excited about his visit too. Before the announcement went up the air, a little less than half of the public class seems to have been blocked by companies wanting to send testers in groups. That is how much people want to be sure they make it in. Not everybody is connected to Moolya Facebook page (which already has more than a 1000 likes) and Twitter (which has got more than 500 followers) so I thought I would write this blog post to help you with details.

There are limited seats only. I am hoping you need to act fast if you really want to make it. The cost is 40,000 Rupees + 12.36% service tax. Yeah, yeah, I know what you are thinking. Not if your company sponsors you because they are the ones who are going to be benefited by you benefiting from this class.

Hurry and don't delay - Register!. Send your registration to sales@moolya.com and payment in advance is compulsory to confirm. Mark December 3rd and 4th for James Bach Live. 

Unleash the true tester hiding in you and if you need help, James can. 

In memory of Ola Hylten

In Oredev 2008, a stylish young man talked to me about testing and he turned out to be Ola Hylten. We struck a connection right from our first conversation and we started feeling friends. The conversation went online once the conference was over. We built mutual respect for each other. So much that we were thrilled to meet again last year November.

Ola invited me home and he drove me to his home and dropped back at the hotel. I had a great dinner at his home and he was asking if he could be the first member of Moolya - Sweden, when it happens. His home is such a wonderful place and it may no longer be the same. I met with his 2 wonderful daughters, his girl friend and his brother. It is still in my eyes, the 3 hours I spent in his home.

Ola was Ola, a fun guy to hang out with. He and I mostly spoke about testing and our community. He cared for our community and its betterment as much as everyone of us who is serious about it does. He was respected by everybody with whom he interacted. I could experience it.  We had several email conversations and moments of laughter, mutual respect, sharing the frustration and happiness. He was so proud to be a part of making Lets Test conference. He told me several times about how much it makes him feel good and great.

My heart is unable to handle this news that he is no longer with us. I would have hugged him in 2 weeks but that won't happen now. I am going to miss you Ola. You should not have made me write a post in memory of you but you did it.

Ola lived a great life, personally and professionally, too. He showed all of us what passion to testing meant. He has now silently ejected himself out of this world.

I am unable to handle this pain Ola. I will miss you.

Story from a company that built "the best software testing tool"

I am sure you have heard of stories of UFO and Alien sighting from many parts of the world. Ask the sales team of this famous company that built "the best software testing tool" and they would tell you that alien visits are because of their tool. The aliens, according to the sales team, needs a one stop solution to all their automation testing needs and that is why they visit us.

If you think I am exaggerating, you are unnecessarily optimistic about your intelligence ;-P. Here is a story that I partly witnessed.

The company that built the best software testing tool, apparently, also built other software products. One of the software products they built was a product not related to testing but something that a lot of people need to use on their computers.  They thought they needed some checking activity to be done. As an example, they wanted to check if certain links load as per mock. This was a no brain job and this company believes in automation. So did they automate those checks? If your guess is - yes - congratulations - you are wrong again. 

They outsourced the work to some large services company in India and called it as "Compatibility testing work" while it wasn't. Large Indian services companies only care for three things - How long is the work? How many people can we bill? How will this help me answer investor questions on the revenue? 

They neither care about testing nor about the future of testers they hire. The job for a tester on this project is to "check" whether the page loads, all images load and a bunch of other things load as compared to mock and design. So, testers have hundreds of links to open and give a report of how many links did not load properly.

What is happening to testers on this project? 

• The testers on this project feel /testing/ is boring job. They are made to believe that they are doing testing while they are not.
• The only thing they have been doing over the last couple of years is to wait for the links to load and say "Pass" or "Fail". That's pure checking and not to be done by humans for those thousands of links.
• The bigger problems are written below
• As they try to move out, the world isn't considering them as testers because the only thing they have been doing is to wait for links to load. 
• Of course, those testers can put big brand names in their resume but they realized nobody cares for it anymore.

So, is that the end of the story? Nope! The above is just a premise of the actual story. 

Several months later, the same large services company of India got an enquiry from one of their existing customer for testing page load compared to mocks but they did not need humans to do it, instead needed automation solution. Notice how carefully, I am not using the word "test automation", in previous sentence.

The services company agreed to do it and a team of automation testers by designation pulled out the best software testing tool and wrote a bunch of tests and at times record playback then tweak to get it done. One time effort and as long as the mocks or designs don't change - this solution works. Its shipped. Works well on rough seas.

Somebody within the services company noticed these two projects and said what I would have said, "Hey, the best testing tool serves the purpose of what we seem to be doing manually all this while" and then the businessmen inside "Sssh! No, it does not. We have a 5 year contract for 20 people and you know what that means to the business?" As far as I can tell you, it is in million(s) US dollars.

However, the company that built the best software testing tool is not a company that is ignorant of this. They are well aware of their tool capabilities but seem to fail in putting their own tool to use for another product within their company. When someone actually told this to the company that built the best testing tool  - they were excited. Excited not because they could save some humans for what they were not supposed to be doing but to change their marketing communication with sentences like, "Case study of how a large services company used our best testing tool to test millions of links". Interestingly they show how the large services company saved millions of dollars for their customers whilst they themselves were paying millions of US dollars to get manual checking done where they did not want to use their tool. 

Moral(s) of the story : 

1. Humans are made to run tests that humans were never supposed to. 
2. When automation kicks in - comparison to humans and automation also kicks in - indicating how poor their understanding of testing is.
3. Business decisions can decide how boring testing can become.
4. Most large services companies remain large at the expense of killing software testing and upcoming testers.
5. Software testing tools are as useful as spoon and fork - they are needed everyday but shouldn't cost as much as a Ferrari.
6. The world needs more bold people than just more skilled testers at the moment. So if you are focusing on training testers, don't just teach them testing.
7. Those who trade their time for money and are designated as testers aren't testers anyway.
8. Most often, companies that are proud of building the best or popular software testing tool are actually putting the field to shame.
9. The best software testing tool is always the human brain. It can operate in "non thinking" mode too and unfortunately seems to be the popular mode among most testers since they are paid for it. 

Exploring Exploratory Testing : Bangalore : August 15 : Free*

Update : In less than 48 hours of this post, there are about 40+ registrations and I am not taking anymore registrations. To those who are in the first 40, they would receive an email from Yagnesh who is helping me help you. You will receive an email from Yagnesh by 12:00 PM IST on 10th August, 2012 with details. Apologies for not being able to accommodate more this time. If you don't mind being on a wait list in case someone drops out, send me your willingness to be on the wait list. However, wait list means, we are not sure if we would still have a place for you.


There are four reasons this class is for free. First, the money I need comes from Moolya. Second, it is Independence Day for India and becoming a great exploratory tester helps in winning your freedom from scripts that make you a slave. Third, the Moolya office can accommodate about 30-40 testers in our main work station area and I don't need to pay anything to hire it for a day. Fourth, it is Michael Bolton's birthday. What a way to celebrate Michael Bolton's birthday!

To add to it : Shmuel Gershon has come from Israel to Bangalore and he is going to participate and present something for us. For those who do not yet know Shmuel, he is one of the fantastic guys in testing, he is the one behind Rapid Reporter and is a Context Driven Test Leader

Venue: Moolya's office at South End Road, Bangalore
Time: 9:30 AM (sharp) to 5:30 PM (blunt)

Topic covered:

• Styles of exploratory testing
• Why testers struggle with it
• Test coverage - as the fundamental approach
• How to use Heuristics & Oracles
• Practice sessions (if you are bringing your laptop)
• Session Based Test Management
• Courage for software testers
• Unlimited Question & Answers

Participants need to:

• Send me an email to pradeep dot srajan at gmail dot com
• Preference would be given to those who have not yet attended my workshops
• No more than 35 participants
• Bring your own lunch / figure out a hotel nearby (there are plenty of good options)

Its time!

Changing a part of the landscape of interviews in India

 http://moolya.com/blog/2012/07/26/thanks-so-much-for-interviewing-with-us/ 

Testability Stories for Agile

You have blood, it has a pressure and it has to be monitored if you want to keep yourself healthy and living long enough. Blood pressure is directly related to heart and its function. As you all maybe aware, most deaths in this world are due to heart attack.

We are so bloody lucky. If we were born in the 17th century and needed a blood pressure test, someone would have wanted to cut open an artery, insert a pipe and then measure how much rise and fall the blood has in that pipe. There is no guarantee we may survive that single test. Since 1855, the situation changed when Vierordt worked on a non invasive method of testing blood pressure. That invention has changed the world. One of the greatest physiologists of the nineteenth century, Johannes Muller said, "the discovery of blood pressure was more important than the discovery of blood". Thankfully, we don't need to be as great physiologist as as Muller was to say that the invention of non invasive way of blood pressure measurement has been critical to saving millions of lives every year.

Not just blood pressure. There were lot of medical tests that were invasive and inventions have helped us find non-invasive ways to test. If that had not happened, every time someone goes to a medical checkup, they would come back with a puncture in the body (if they were still alive)


The introduction of non invasive ways to measure blood pressure and many other measurements related to health are excellent examples of good testability. The MRI, CAT, Doppler, CT scanners are result of humans thinking of good test-ability mechanisms. This has helped doctors to do better and faster diagnosis of health problems and indirectly save lot of lives. Without good test-ability layers in health sector, our average life span would not be as high as it is today. Testability has improved so well that my grand mother uses a device at home every week to test her blood sugar levels, despite it being invasive. In the future, an iPhone or an iPad may be equipped with apps and hardware that may do non invasive tests and auto report to the doc or auto fix an appointment based on the reading.

Testability, is "the not as famous as it should have been, yet a fundamental thing to help in diagnosis". Be it in tests for health or tests for software.

My introduction and experience of testability

I first heard & read about testability 3 years after I became a software tester from James and Michael. Once I learned testability, I found that the root cause for many problems in testing software when investigated branches back to testability. No, this is no obsession or confirmation bias towards testability.


In 2008, I got a call from a company in Bangalore. Somebody had pressed the Panic button in the organization about performance of the product and they could only find me to be the independent tester available to give them a neutral opinion. I hadn't done much work on performance but I took it up. They wanted me from evening to next day morning because they had to make a release decision the next day. They gave me a feeling that I was Tom Cruise of Mission Impossible who has to accept a mission midst of nowhere. I took it up. On the way, I browsed through Scott Barber 's work and called Rahul Verma and asked him if he would be fine to assist me on phone if I were to call him midnight :)

Before I could start testing for performance or thinking about calling Rahul Verma, my opening move was - is the code testable for performance. It was not. Tool integration did seem like a project in itself. Doh! Panic, for sure. Also, it couldn't take 5 users, why load the poor guy with 10,000?

Several years after that, I met a bunch of "performance testers" of large services organization and I probed them on their experience of panic and call for performance testing. They had a similar observation as I had, although they didn't use the word "testability".

You may have read this experience report from me on checking and building check automation. James Bach blogged about it and made specific mention of how he perceived this story to be about testability.

Using versus controlling 


About two weeks ago, we were testing a web application used by just a few hundred million people around the year. We found a bug in production which is of  "Oh my Gosh" types. Fortunately, we had kicked in a video recorder and we captured it. We have the evidence that it exists but we are finding it difficult to reproduce it. No, not that we are not aware of what we did but this particular bug occurs after a specific error from the server. To disprove our own assumption, we need to control the server. In some large organizations there exists an IT infrastructure team that controls the staging environments and testers don't get access to control it. They just use it and are happy just /using/ it. Without being able to control system under test, merely using it won't help test better.

The sin of closing a bug because it can't be reproduced & its link to testablity


Going back to my days of being managed as a tester, in several organizations, my team was asked to close bugs that are not reproducible. I have heard and seen plenty of test and dev managers do that. When I picked up some wisdom in life, I realized how foolish the decision of closing not reproducible bugs was. Some testers defend the decision but are unable to reproduce it. They know they have a problem, unfortunately, they don't know they are facing a challenge of not having test-ability.

Control power to testers

There are products that do not have GUI at all. Not having a GUI shouldn't stop someone from testing the way they would do if it did have a GUI. Of course, we could write code that tests but it is difficult to alter a test when its running through automation. The human brain is wonderful at doing that. I change tests as I see some information and get curious if I would get a bunch of different set of bugs and do a different coverage.

Finding Nemo exercise to help teach testability


Have you tried it? There is an exercise I created to help testers practice reverse engineering or what I thought was reverse engineering. If you want to download the exe directly, here is the link.  There was a hidden lesson about testability in it. I now have enough evidence that most testers who worked on it in my workshop never said they were annoyed by the constraints I had put in or asked me how they could get out of the constraint I had put in.

This, I believe is a small slice of how they work in organizations without asking for testability. I wish every tester was first taught testability even before teaching how to test.


Process Explorer as an example of value of testability


One of the utility I discovered through the help of my student Mohammad on Windows was Process Explorer. This gave me an amazing view of a list of printable strings in a running exe.

If you were to run calculator and then go to process explorer, you would see calc.exe running. When you right click and go to properties, you'd end up with multiple tab window open. One of them contains printable strings in calc.exe.

One of them said, "This operation may take a long time to complete". Wonderful. So, if this is the output I have to get, what should be my test was the question.

I did a bunch of tests to figure out that a factorial had the power to make calc.exe say, "This operation may take a very long time to complete". I then applied Ben Simo's FAILURE mnemonic and found how unhelpful the message was plus perusing through other printable strings, I could do a error message coverage for calc.exe. I found an impressive list of problems, rapidly. It was a wonderful feeling and I wanted it to continue across all projects I test.

I thought it is a luxury to have such visibility and testability tools in all projects for the coverage I wanted to achieve. I was wrong. I recognize it is a basic need. I know how to get it. It doesn't matter if I know, it matters if we all know.


There are ways in which I hope we could solve this problem and here are some of them

Testability stories


Believe it or not, there are two types of Agile teams in this world. The first one in which testers and developers have equal responsibilities to test and work as a team with high collaboration to resolve problems. I have heard and read stories that such teams exist somewhere in the world. Maybe they are in India, too. However, almost all teams I have consulted in the last 2 years that claimed to be that type of Agile, were not. Call me unlucky or call me an expert in consulting teams that pretend to be Agile, it would suit me.

I was wondering if we have a set of testability stories to be built while the product is being developed it would be of great value. As you know and agree, testers are also users of the products, there are no stories written considering testers as users of the product. It always focuses on end users (who are probably customers). Here are some examples of stories I am thinking:

• Testers would like to have this specific error occur in order to be able to perform tests related to recovery from the error
• Testers would like to be able to inject values that violates the front end validation because thats exactly what hackers would do
• Testers would like to integrate a code coverage tool to test what areas of code are they not hitting through the tests they think are great
• Testers would like to have test doubles to test for interaction of our software with third party components whose code is not in our control
• Testers would like to control the time delay in which a certain business process starts running to help achieve time based coverage
• Testers would like to try and add users to db via an excel loaded with values instead of having to key in a set of test users every time.
• Testers would like to have a log of every time someone clicks on the following links to monitor how people seem to be using it
• Testers would like to have statistics shared from the production environment on which pages get maximum hits and what are people searching for mostly and what times have peak traffic
• Testers would like to track all malformed requests that come to the server to monitor any hacking activity or trace of attempts to hack

It could be domain specific, product specific, testing generic and much more. Adam Goucher blogged about what Michael Bolton suggested as Design for Testability and Brian Marick has this wonderful essay on Testability and you would see that we all are thinking in the same direction - to help exploratory testers do better testing, faster and more frequently to help them do better test coverage.

If code needs instrumentation to accommodate testability stories and requests, it should be written in such a way that it does not disturb the sytem under test, can be removed or turned off before putting into production. Worried about this branch going to production - discipline of discipline can help prevent such problems or if you love automation, so be it.

The new idea here is about having identified the need for stories dedicated to "testers as users" of the product. This helps add layer and value to testing. When I say testers here and you belong to the real Agile team, please substitute it by "team" because it is everybody's responsibility to test, isn't it.


Review of this idea


I wrote a first level draft of this and sent to a bunch of people (from the huge set of people I could have sent to) whom I knew would help me out bad set of ideas out in public. It is their feedback that have helped me revise this to its present form and I would like to thank Paul Carvalho, Ben Simo, Rahul Verma, James Bach and Michael Bolton for their review. These people helped me identify the strength and the context in which this idea can be highly valuable. I am sure if they read this published piece, they would realize how different the first draft was compared to this one. That  is how much influence their feedback has had on me and my writing on this one. I have thoroughly enjoyed the journey of thinking about this idea to writing down several drafts, researching and re-reading many articles and getting this to a point where you are done reading it :)

Fletcher Lynd Seagull

I am not Jonathan Livingston Seagull. James Bach is. I am Fletcher Lynd Seagull. At a time when I was asking how do I fly fast and swoop like birds should ideally do, I met Jonathan Livingston Seagull who along with Michael Livingston Seagull and plenty others taught me how to fly and swoop.

They set me free from the crowd and here I am, appearing to most likely do what they did to me.  Not all birds want to fly and swoop, they are just happy sitting in the sun and picking up a fish that pops out of the river. It matters a lot to identify, care and help the birds who want to fly, learn how to do it. Every bird is born with an ability to fly but the kind of flight that birds can do requires tremendous amount of skill which comes out of passion to fly, perseverance towards practice and focus.

The beauty of teaching birds how to fly fast or swoop is, I get to learn equally good things from the bird I try teaching. Every time a bird that claims to have learnt something from me demonstrates its flying skills, I get inspired. That inspiration makes me want to do more.

To contradict my previous paragraph, I don't teach birds how to fly, I just act as a mirror and show them how they appear to be flying now and ask them is that how they wanted to fly. They make the corrections, not me. I am humble but as I fly higher than birds who do not want to fly, I may not seem to be. They are not supposed to be there. They are supposed to be here. The air is thick and cold but the fun here is more.

Some of my colleague birds work with me in Moolya and you know who they are. Some want to take a different path and if I did oppose that, it would be ironical to what I have learnt or teach.

Read an inspiring story of a bird from India, who recently set itself free

Signing off for the moment,

Fletcher Lynd Seagull

Weinberg on more than writing - the Fieldstone method

11th March, 2012 in Bangalore was a beautiful Sunday. Now that it is almost over, I can use the past tense "was". Just the weather making it beautiful is one part but what about the weather within me? I decided to make it beautiful within. Everybody has a pile of books that they bought but never paid its due attention. Weinberg on Writing ( WoW as I want to call now) - The Fieldstone Method was one of the books that hadn't got my time yet. So, I read the first chapter at home, closed the book, went to my wife and asked her if she had any plans for the afternoon. As I had taken her out yesterday, she excused herself out of any plans. Whenever a husband asks "What's your plan?" to his wife, it means, "I have a plan and want to be sure if your plan doesn't disturb mine" :). I took my backpack and scooted to a coffee shop nearby. Coffee, book reading and relaxing was my plan.

About 2 PM, I was all set. I wanted to start with Camomile Tea. I had told my wife that I'd be back only when I am finished with the book, so I was hoping there would be a couple of beverages. I realize now that there is nothing like "finishing the book" because The Fieldstone Method provides an experiential learning to those who want to work with it. Not just that.

I have had the great opportunity to meet with Jerry and spend a couple of days, attending his workshop, being a part of a peer conference that had Jerry, a conference and much more in 2008. I have been a reviewer of Jerry Weinberg's book "The Perfect Software and Other Illusions About Testing". I have read a couple of other Jerry's books that have changed me from time to time. With this book, I felt Jerry sitting next to me and coaching me on the Fieldstone Method. This is no hallucination. I am sure the emotions he had while turning the stones that he used to build this book has rubbed on me and has caused some very good emotions within me. Jerry intends that happens with the experiencers of the book. / OK there is no such word as experiencers in any dictionary /

I haven't published a book yet. If you are thinking I haven't written one yet, you are mistaken. I just haven't published it. I see the light now that will lead me to publishing. That's what I seem to be getting out of The Fieldstone Method because I am going to build my books not write it.

So, why am I telling you all this? To get you buy the book and experience it? To write a review of the book?    You will discover why I am writing about it, if you were to continue reading.

It is all about me. I recognized that I had almost stopped note taking. In other words, I had stopped collecting fieldstones. I guess I was just processing whatever my imperfect memory could store. Isn't it amazing that I stopped doing something that I advocate to other testers - note taking. When I realized this while experiencing the book, I picked my backpack and searched for my Indian version Moleskine and a pen. I must have missed observing a trillion stones but thankfully I have now saved myself from my ignorance that would have led to missing trillion power trillion stones in the future.

Here are some of the stones I collected today that I am pulling from my notebook (and typing it for you):

• Thought: When you are alone in a coffee shop, you hear people and their conversation you usually wouldn't bother to hear if you were not alone.
• Retrospective as I read the book: I was probably smart all this while but not happy because I always wanted to be more smart but never wanted to be happy.
• I shook the coffee table accidentally and a glass of water placed on it started to get its vibration and then I wondered: Pradeep, when was the last time you observed water settle down after being disturbed with a vibration. Your 9 month old kid now would watch it with curiosity. Relation to testing: The first time an information looks interesting and everybody pays attention to it. Once they learn how it happens, they lose interest to observe things that they were once curious about and if there was a different behavior? They would continue to assume they know something. Software is volatile, just like the water. 
• I was asking myself a question: Does it matter if something takes a long time to learn? What determines "long"?
• I saw cold coffee on some table and decided to order it. I wrote a note : How did my choice alter after seeing something that caused my brain to demand it.
• Project Gutenberg quoted in Jerry's book - Awesome

  A friend of mine, Nandan Pujar wanted to meet with me for a consultation and I felt, "What a great time for a good friend to come in. Some of the exercises I want to practice requires such an occasion and a trust worthy friend". I took notes as I was consulting for him:

• I was reminded of Warren Buffet interview of why he didn't come and invest in India prior to last year. His response was, "Nobody invited me to do so". 1.2 billion people didn't think of knocking that door that way. I felt sad for myself.
• My friend Nandan said, "Being with mediocre people helps you identify your delta with them and being with intellects helps you fix the delta". I thought it was a cool thing.
• Made note of words he used "Feudal" and "Artificial scarcity"

 I came back home and made other note of stones I saw, heard, observed, felt, experienced...

• My 9 month old daughter had to poo. After cleaning the poo, I wrote in my note: As a kid I must have not known this is called "poo" and why people clean it off. Now that I know, I clean the mess I do. I am wondering if testers who recognize the "poo" of their work will ever clean the mess they do. Some of them are stuck with it and they seem to think as though it is a newly grown part of their system. Some who come new to the system see people stuck with the "poo" of their work and assume that, to be experienced, they also need to be stuck to "poo"

It is fantastic. I love it.  Thank you Jerry. You helped me recognize the "poo" I was carrying all this while and I am not going to be one of those who will not clean it. I will clean it. I will not just clean the "poo" I have been carrying for a while but identify with the help of trillions of stones I can see, to not carry any type of "poo" of my life. I also recognize the idea of heuristics and they are fallible.

Till yesterday, I was thinking, "Now that I have accomplished all this in life, how do I change myself?", Weinberg on Writing (or WOW) - The Fieldstone Method is a change catalyst. 11th March, 2012 was a beautiful Sunday in Bangalore. So can everyday be if I were to collect the stones.

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!