A culture bug that impacts software testers in India

We all know the way we have been brought up has had a huge influence on how we see things. Some of us have benefited and others have not. Most of us have a mixed bag.

A culture bug in India

Each of our countries has a culture that has rubbed off on how we are brought up. Indian culture teaches respect. If someone is elder, no matter how stupid they are, kids are taught to respect them because they are ELDER and they are always correct. There could be a notion that elder means wiser but sadly, that is not true in many cases. If someone is a senior at work, no matter how much they are sinking the boat, we are taught to respect them because they are SENIOR and they are always correct. If the teacher at school did beat us up for not doing home work, we were taught to not be worried about being hit but instead feel guilty for not doing home work because they are TEACHER and they are always correct. At least till the previous generation, women were mostly considered to be electricity-less Roti makers by most men and also were considered less intellectually superior. So, women had to offer a lot of respect to men irrespective of how screwed up the men were. That was the case because they are MEN and they are always correct.

Slowly, over generations, the people who are offered respect have learnt to misuse it. So, there are plenty of organizations who say to their testers, "How dare you speak like that to the CEO?" and "I am your reporting manager and I can screw your career", "If you don't do things to please me, I am going to impact your hike and promotion", "How can you go to my manager and talk about me?"

Those who offer respect also have a tendency to think that they are less superior or less powerful and this makes them act like a slave, not escalate issues, not inform the decision makers the truth and allow someone to screw up the entire company and its culture. It is simple, when the boat sinks, move to another boat. This is why hiring has become a challenge for organizations who want to grow. They got to be careful that people don't see the boat as "yet another boat to sink".

Similar culture bug in other countries

Other countries have their own version of this problem. For instance Malcom Gladwell, who happens to cover great stories, exposed how culture impacts plane crashes. In the book Outliers, Malcom covered The Ethnic Theory of Plane Crashes. If you were to read that piece of brilliance of thinking and writing, you would know Korean Airways had the highest number of crashes in 70's and 80's because their culture was in such a way that the co-pilot did not oppose the captain because he was a SENIOR and by virtue, a senior is always correct. The story gets a twist when the culture is hacked and people are re-trained on how to and not to respect the senior. As of today, Korean airways is one of the safest, at least, as per Wikipedia, there is no report of plane crash in Korean Airways since 2000.

If that happened in Korea, it must have also happened in India. I was trying to see if any plane crash in India had a similar pattern. The most recent plane crash in India was the one that happened in Mangalore where 152 passengers and crew were killed in Air India Express Flight 812 crash. You should read this part and figure out that the co-pilot warned the commander but the Serbian commander didn't heed to the warning because the commander was the SENIOR. Without guess, thousands of air travellers might have been killed by the human bug of culture so far. The West can't be different than east as I believe, the West houses humans as the East do. There could be a different culture bug there than in here.

When is it OKAY to give bad news information that hurts people?

In Moolya, there is this wonderful young tester by name Manju. Her passion to work, dedication and commitment is unquestionable. She is highly trust worthy. Our customer seconds my understanding of Manju and has high respect for her commitment and trusts her. However, there is one aspect of Manju that is a side effect of all the good qualities she has - which is - she does not say anything that hurts anybody.

The nature of the job as a tester, is to find information and present information. Not all information is welcomed.  Some information could violate assumptions or shatter the possibility of a goal being accomplished and this can definitely hurt. It is the information that does hurt, not the human who hurts another. So, stop confusing yourselves that testers find bugs in people or their work.

With Manju, I have been repeatedly trying to hack into her thought process and help her learn that it is absolutely okay to speak in ways that may hurt people if it is helping the larger objective of why she we was hired for that project. 

In my most recent conversation with Manju, I gave her an analogy, "I am the captain of a ship you and I are travelling. If someone is hammering the ship to make a hole so that water comes in and the ship sinks, would you inform me about it?" and without giving her time to answer, I continued, "You should! Otherwise we all sink. If you do escalate things to me, I may throw the person out of the boat but that is because I am the captain and I want travelers like you to feel safe on this boat. It is a captain's duty to do so and it is your duty to keep the captain informed about it". I pray she gets it and I shall hack in every time into her 20 years of education that says, "Don't say things that may hurt people". I have suggested her to read Malcom Gladwell's coverage on airplane crashes and the culture bug. I am sure she would understand that saving thousands of people is more important than hurting the captain with bad news.

There is so much of value she has added to the project that she is now leading the delivery for the project and this came to her because of her good work. It would be more valuable if she were to be telling things the way they are without being worried if it would hurt somebody or not because, at times not telling such things will sink the boat she is in, irrespective of how much she cares for the safety of the boat.

The Indian Military and how they don't confuse the reverent culture

I was talking to Paul Carvalho over Skype yesterday and he was narrating a story about how he established his position as a test consultant a couple of years back. He had to oppose certain decisions taken prior to his appointment. He had to help his company recognize that they actually hired him to solve the problem. I told Paul that I would wish to hack into the culture of some Moolya testers and help them do what he appears to be doing. He came up with this beautiful thing asking, "Maybe you may want to explore how better you can use your own culture to teach them than bringing in examples from other cultures"

James Bach spoke about how Indian testers can benefit from their own culture in his talk at Test-Ed 2012. He also delivered great reminders to Indian testers on how they seem to have forgotten the wealth of information that exists about testing in India from its history and mythology. He referred to the Indian culture as a reverent culture and said there is power in it.

While we should learn a lot of good thinking skills from Indian culture and history we should not misunderstand reverence to offering respect at the cost of the purpose. Paul's question triggered a thought process in me that he found it profound. Here is how it goes:

I said to Paul that I am not bringing examples from other culture to Moolya testers to change their culture but to help them remind how the Indian Military forces work despite our reverent culture. Their job is to be prepared, remove obstacles and keep progressing.

This learning comes from a conversation I had with my cousin brother who serves the army as a Colonel who fought the Kargil War in 1999.  In 2002, then a Major and Joint Commanding Officer at the Jawan Training center in Secunderabad, I had an opportunity to visit him and see the rigor that our Jawans go through to get trained to fight war. The documented rule in the military says, "If a SENIOR is a coward or creates panic at war zone, runs away at the hands of enemy and fails to fight the enemy, he can be killed by any officer who notices this, irrespective of their rank". If they fail to kill such a person, the panic or cowardliness could spread and we shall end up losing the war. Acting upon information is leadership. You don't need a designation as a Leader to be a leader.

The non obvious thing about software business

In the software field, it is less obvious that many families are dependent on the work we do. For instance, Manju works for our customer who is a start-up and boot strapped. The founders are pumping in all of their money to get their business going. They have families and need to earn bread for their family. They also need to pay their employees and vendors on time. They are more or less in a war like situation. They need to know the obstacles before they have to encounter it. They can't see obstacles and they have to rely on their people to do so. The more their people understand this, the better it is for them. If they happen to lose business, that would spiral on their employees and vendors like Moolya.

Well, it is not always that somebody was intentionally hammering to sink the boat. Software is so complex that at times people may remove a nut to fix something else and that may have caused water to leak in. If it is escalated early, the captains have time to fix it. Otherwise, they need to work on Plan B of getting everybody out of the boat, safely. That's not what you should make your captains do.

Recognizing & fixing the bug

For someone fresh out of college and in the first job, how much would they be able to recognize that a leak in the dam can cause the entire dam to break? With a boat, it is obvious, maybe. In business, it is not obvious. Even to those who are running the business. The young folks need to be trained – to recognize leaks and to escalate or fix it.

It is not easy. 20+ years someone has lived a life in a specific way and for me to win their trust to hack their culture looks like a thing beyond human capability. Interestingly, I just can't tell people like Manju to speak up and assume my job is over. I have to create an environment where people who speak up are protected, people who speak up are respected, and people who speak up understand the purpose.

Informing the purpose, reminding them, demonstrating their stake and helping them understand the purpose is my way of how this culture bug can be fixed. You can't be a doctor and say, "I hate seeing blood". You can't be a tester and say, "What if this hurts somebody?” Note that, please, I beg you to be careful - testing does not mean to find bugs in people nor their work. It is about finding and presenting information. The information can offend some people because they may have had an assumption that is violated with it or were in fantasy and you brought them to reality. That is why they hired you. Even if they don’t recognize, you have to.

While getting this reviewed, Paul Carvalho, reminded me of Virginia Satir interaction model that he learned from Jerry Weinberg. Then I happen to read this beautiful piece from Dale Emery about his experience with Virginia Satir Interaction Model and I know the training is both sides - to those who want to bring issues to notice and to those who are going to respond to it.  

My heartfelt thanks to Manju who permitted me to use her name, my observations about her and recognizing what I said is true about her. Thanks to Parimala Hariprasad and Paul Carvalho to help me see blind spots in my thought and writing. Many thanks to my cousin Padmashree who is of K12 and took time to read this and tell what passages are simple and what are not. I have acted upon the information she provided. To bring this post to you, I have had to work, for more than 36 hours (over a period of one week) and what a moment for me to know you are reading it. Thank you! 

Testing for a product demo - experience report

~10 years ago

In 2003, I worked for Impulsesoft, a start-up company that claimed to be first in demonstrating CD Quality (which is 44.1 KHz sampling, at that time) stereo music over Bluetooth. I was extremely proud to have been a tester for the world's first Bluetooth Headphones. At that time, you may have called it a bleeding edge technology.

On a yet another beautiful Sunday morning I got a call from my manager to help someone in the marketing team who was flying to Germany for a conference. He was flying to a conference which had delegates who were potential buyers of our product. At that time, I don't know if the business model was B2B or B2C.  However, there were a few known crashes of the Bluetooth Headphones I was testing. I knew those crashes, after all, I found them.

My idea was to help him learn to not do anything that makes the headphones crash in front of the delegates. I gave him a list of do's and don'ts. I also demoed it to him on what would be happy path and what would be a dangerous path. I remember telling him to be careful of making the claims to potential buyers. On inquiring him I found he was seeking my help few hours before he was about to board a flight to Frankfurt. I did my best and wished him good luck for the demo.

2 days later, I get an email forwarded by my manager. With no surprises, the email had a content like, "Pradeep didn't test well, there are plenty of crashes and our potential buyers were not happy to experience it" written by the marketing fella whom I had coached on do's and dont's. I was called for a meeting to explain the same. I went with a print out of how we had already reported those bugs and with an explanation of how last minute prep for a demo like this is a bad idea.  Thankfully, my manager and the CTO were sane to understand. So, they said, "this is not a meeting to catch you responsible for it but to check how did you help the marketing guy".

I was excited about the whole experience. I started to think I could have done a bunch of stuff if I had time and I could really help customers. Later, I improved upon my approach to help customers and my employers if they were to ask me to "Test for Demo"!

~ 8 months ago

One of Moolya's customer is Cogknit. They are making products in the e-learning space to take the e-learning to i-learning and have been liking what Moolya has been doing to their product. They are boot strapped start up, young fellas, big dream and lot of sacrifice to get to a position where they are right now. About 8 months ago, they informed me that they were to be giving a demo and sought for my help.

I was so excited to bring in all my experience and expertise on this matter to Cogknit and gave this a high priority. I donned upon the role of Demo Test Architect without having to seek anyone's permission for it.

I had a meeting fixed with the founders of Cogknit and asked them a bunch of questions on

a) the conference - World Education Congress
b) the delegates (the potential buyers)
b) the objective
c) the demo plan they had (no matter how primitive it was)
d) their assumptions on what would not block them from delivering the demo

I set up a meeting with the developers from Multunus who were helping with the GUI and or front end, developers from Cogknit, testers from Moolya, the marketing fella - Deepak (co-founder of Cogknit), and Anuroop (the founder) with an objective to bring all to common ground and brief them about my plan and interest.

As a next step, I asked Anuroop and Deepak to give me a demo of what they intend to demo and I kept recording the steps they followed.

I did my home work on what could go wrong. For instance when Anuroop was demoing, he had already logged into Nimit (the web based i-learning product). I asked him to logout and then login again, start from first. Surprise! When he tried entering the password quickly, he made a mistake and bang, an error message, blood red in color appeared. At a demo, customers don't intend to see if errors are handled well but would want to see more of how the product works. There were too many blood red error info displayed for other actions that went wrong. If Anuroop were to accidentally type something in the search whose results are zero then the blood red appears which is good maybe for users but here there are no users except Anuroop  and Deepak who are going to be demoing.

My further homework and thinking suggested that the demo ready version of the product may not need to have these error messages at all. I held another meeting and requested the developers to give me a version that has no error messages displayed. "Remove all blood red" was my instruction. Probably, all of that code commented. I asked Anuroop to give me a demo again after the change happened. We also changed the password to something so simple that going wrong typing that is a sin :)

We went through multiple iterations of demo practice and kept tweaking the product to make it more suitable for demo.

I am guessing that Anuroop might have thought - why is this guy trying to teach me how to use the product I am building :) All for a good reason, dear Anuroop! The testers on the team supported me with a Don't Do Anything Like This list. As an example, to copy paste from their recommendation:

Do not drag & drop any book from the "Library" row to the Mashup tray The books other than Mashup shown in the "Library" row are either rented or bought contents. So, mashup of rented or bought contents are not allowed. 

Even if Anuroop accidentally did this, the product wouldn't shout, "Hey, here is an error message for you"!

My goal was to ensure Anuroop didn't do any of this. So every time he gives me a demo of what he thinks his demo is, I secretly run through the don't do this list to figure out if Anuroop is crossing the boundary of product areas marked as danger.

There was also a plan to make a feature work in the last minute and get it for the demo version. I humbly rejected the idea. No last minute changes to the product was my directive.

Once I had a version that looked to me as what can be presented during demo, I asked my fellow Moolya testers to run it through automated checks and exploratory tests and give me information that could make my decision change. I personally also toured the demo version of the product to find if my oracles help me be warned of something I should be. Things were starting to look OK barring a few minor changes needed.

The conference being on a week day and hosted on the same server where test instance and dev instance was running, I gave a directive to ask people to stop working on the dev / test / demo instance 2 hours before the time of the demo and wait for confirmation of demo over to re-start their work. This is to ensure nobody ends up doing anything to the server, even by accident. So, there was a stoppage of work for several hours during the demo.

I made a list of infrastructure requirements and checked the laptop they were getting for demo and made recommendations to turn off all alerts of the OS, Anti Virus, Apps and other nuisance that could disturb the demo from going smooth. I can't exactly remember if all of that was done but I guess Anuroop did mention that he would take care of it. Probably he did.

Then about internet connection for the laptop. I made recommendations to carry backup of internet dongles and to check at the venue a day before on the connectivity. Deepak and Anuroop did do a on the stage previous day test of internet connection and deemed it to be good enough.

During these days, the only question I kept asking myself, "What could I be missing?". A new idea kept emerging and I kept refining things better.

Last 2 days before the conference was more awesome adrenaline for me. Continuous stream of ideas and thought process. All through this period, I kept updating my notes and updating them to keep them reminded of what I am capturing and if it needs correction.

So the real D-Day came and I was nervously calling Ullas every one hour to check if Anuroop or Deepak were done with the demo and if they have any issues that they would need my help. I didn't do any other work that day and was totally thinking what would be going on for the demo. This was not nervousness, it was excitement to see the demo go well and feel happy about all the effort I took to get it going well.

The demo did happen, thankfully but the internet was slow. Thankfully nothing did time out or I heard that way. However, the next thing I include in my list is changing time out duration to ensure slow internet connections don't scare too much. The demo did generate good business interest for Cogknit and they got inquiries from Singapore and other countries that I don't exactly remember.

To add a feather to the crown, Nimit was awarded  The Most Innovative Learning Software Product. Here is a picture of Anuroop (right) and Deepak (left) receiving the award from his excellency Nurul Islam Nahid, Minister of Education - Bangladesh & David Namwandi, Minister of Education, Namibia

Anuroop and Deepak receiving The Most Innovative Learning Software Product from his excellency Nurul Islam Nahid, Minister of Education - Bangladesh & David Namwandi, Minister of Education, Namibia in World Education Congress 2012

Many thanks to Anuroop, Ullas and Deepak for being patient with me during the journey and allowing me to play the Demo Test Architect role. Equal good thanks to the developers at Multunus and Cogknit (especially to Himanshu) for supporting me on this. A special thanks to my own test team who have been helping Cogknit for more than a year now. Cogknit got their first big paying customer as well recently and they are sailing to get more.

I just hope, my colleague, Dhanasekar would be as proud of me as he is about Apple on how they prepare themselves for a product demo. More experience reports, coming soon.

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 :)