Letter from India

This letter is targeted to managers in North America and Europe who outsource their test execution work to India. If you happen to know such a manager or such a manager is your client, you might want to share this letter with him, after reading it. That doesn't mean, you shouldn't share it with others ! :-)

Without killing your curiosity ( or to build your curiosity ), here is the letter from India that I am talking about.

In the movie - Shawshank Redemption, Andy Dufresne ( Tim Robbins ), wrote one letter every week from jail for years together, to get funding for the prison library and when it happened, the jailors felt a "miracle". I don't know if I want miracles to happen but I am sure, Andy has inspired me to write more letters in future.


-- Pradeep Soundararajan - pradeep.srajan@gmail.com - +91-98451-76817

"Pradeep's first language is not English--his first language appears to be testing." -- Michael Bolton

Tester Tested interviews Braidy Tester

Braidy Tester has been interviewing great testers for Dr Dobb's Journal. I think I should say, I was just lucky to have been interviewed by a great tester like Michael Hunter.

Michael Hunter blog is widely read in India too. In fact, it is one of my friend who told me that my interview has appeared in Michael's DDJ blog and I blogged about it: Braidy Tester interviews Tester Tested .

You might want to check http://thebraidytester.com to know more about him, his bio, his articles and presentations.

Michael Hunter is an Expert Tester and Test Architect for top secret projects of Microsoft. Lucky Microsoft!

I thought why not I interview the interviewer - [ Hunter hunted :) ] So, here it goes...

PS: What does "Braidy Tester" mean to you?

MH: “The Braidy Tester” is my personal brand. I often braid my beard (as you can see on my MSDN blog [http://blogs.msdn.com/micahel]). When I was preparing to start that blog I spent some time contemplating what to call it. I wanted something snazzier than “One More Microsoft Tester Blogger”. Eventually I decided that weren't that many testers who braid their beards, so I settled on "The Braidy Tester".

PS: How has your experience of interviewing great testers been, so far?

MH:It is a lot of fun! I enjoy hearing other people's views on testing. I especially enjoy hearing about their favorite bugs!

PS: If you chose to answer one question from your own interview, what would that be? and what would be it's answer?

MH: I'll pick "What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?" I think the most important thing for a tester - or a developer - or anyone - to know is that they will never know everything and so there will always be something more for them to learn. The most important thing for them to do is to go learn it! Learn about testing, development, design, art, music, geography, calculus, how people learn, whatever. I find that everything I learn about has something to teach me about testing.

PS: How do you test the code you write? ( after all the great testing experience)

MH: I am a big fan of unit tests and Test Driven Design. I am way more confident in my code when I have TDD'd unit tests backing it up! I also think about testing while I am developing - what tests will be interesting (and will my code survive them), how can I make my code more testable. I look at my code through white box, grey box, and black box glasses. I run through the checklists and mnemonics I've developed and acquired. Then I give my code to other testers and learn what I missed!

PS: There is a lot of confusion over terminologies and definitions in testing, in my opinion. If you feel the same, how do you handle the confusion when you speak or communicate with a tester whose definitions and terminologies appear to be different from yours?

MH: This can definitely block productive conversations. The first - and often the most difficult - step is to realize a conflict in definitions exists. Once you are aware of that you can make the conflict explicit: "It seems to me we don't all mean the same thing when we say 'dogfoodable'." Then you can proceed to form a common definition.

PS: What thoughts run through your mind when you find a bug in a product you bought.

MH: First I say "Hey look! A bug!" And show it off if it's cool enough. Then I wonder how the company missed it. Then I ask "What would have to be true in order for this company to ship this bug?" That last question is the most interesting I think.

PS: What has been the heights of you enjoying testing?

MH: I enjoy finding bugs. Especially the ones which take time and skill and effort to track down. Showing bugs to developers is fun too. My biggest thrills, however, come when I help prevent bugs from occurring in the first place!

PS: There is always something to learn from everyone and everything around for testers. Do you have an experience that you learned something from a kid?

MH: I find watching children interesting because they are so inquisitive. The younger they are the fewer assumptions they seem to make. When I talk about testing I suggest learning to think like a two-year-old: develop the ability youngsters have to come up with an endless stream of questions about everything. Poke at everything in many different ways and you will almost certainly find a case your developer didn't expect!

PS: Tell us about a ( or a set of ) question that you have been asking yourself and how you found answers to them?

MH: When someone else finds a bug in my area I ask why I missed it. When someone finds a bug in my code I ask what I can do to not make that mistake again. A lot of what I am looking at right now is how I interact with other people. Why did I react so angrily to that person? Why am I happy to help this person and not this other one? The more I understand about how and why I interact with people the way I do, the more I can change my interactions to be more effective.

As for finding answers, partly I formulate theories and test them out. What if I deliberately pause two seconds before I respond or react to something? What if I focus on what the other person is saying rather than deciding what I am going to say in response? I find journaling to be helpful as well. Writing things down helps me figure things out, about bugs I am chasing down, about code I am designing or writing, and about myself.

_ end of the interview _

He started this interview with a word, "Fun" and I am not surprised at all. He enjoys testing and thinking about testing so much. His blog is a addictive for passionate testers. After reading, "Making developers cry since 1995", would you ever want to miss this guy's writing?

Thanks a lot Michael Hunter!

-- Pradeep Soundararajan - pradeep.srajan@gmail.com - +91-98451-76817

"Pradeep's first language is not English--his first language appears to be testing." -- Michael Bolton

Developers Developed by Tester Tested

I was testing a product last year in a capacity where the development team was just a floor away from me. Initially, I found so many crashes during the first few releases and there were crashes that I could find even after a couple of months and that's bad ( may not be too).

I take the credit of making those developers to do a better unit testing. I did not do that just by finding bugs but did a few things that I'd like to list for you:

1. Festivals and realizations:

One day, I went to the developers with a print out of heuristics and test data that I have been using to find crashes that made them sit and fix bugs, during festival season. It's painful to sit in office and work when the whole nation is celebrating. This psychologically affects them and in my opinion, developers need our help to enjoy festivals and weekends.

So by giving them my customized cheat sheet, I made them aware of those tests that have made them work during festivals. I did not say anything more than that during that meet. Some changes are set to happen by it self, all it needs is a trigger and I provided it.

Outcome:

1.a. Developers used my cheat sheet for unit testing.

1.b. I forced myself to think of more test ideas to find more important problems, quickly.

1.c. It became easy for me to ask the developers, "please send me your unit test results".

1.d. One of them told, "I am using this sheet because I want to enjoy my holidays and not that I want to do unit testing". Whatever is the reason, I am happy that they are doing!

1.e. The unit test results they produce, gave me new ideas.

2. Two to tango:

I frequently consulted other teams during "critical moments" ( as they call ) that they faced. I once had to pair with a developer for a testing activity.

It was a little gimmick that I played with him that got him thinking of doing unit testing better than before. All I did is to say, "Hey, you better close your eyes and don't see what I am doing. I would do some little tricks that testers usually do to find some important problems. If you are careful and observant, testers like me might not be able to find bugs in your code".

Outcome:

2.a. Had I continued without that gimmick, he might not have opened himself for a careful observation of the kind of tests that I did as any other developer to my knowledge doesn't carefully observe a tester at work.

2.b. He unit tested and then said to me one day, "Pradeep, you shouldn't have showed me the tricks. Now my testers are facing a tough time to look for those crashes that they usually find in my code". I just had a smile in my face. I was convinced that he didn't understand what was running in my mind but that's fine with me.

2.c. Maybe the testers of his team might have come out with more test ideas than to look for the same crash that they are accustomed to. Well, I admit I don't know about that but it's my guess.

3. Patterns and structure of crimes:

Sherlock Holmes, as many of you might know still lives in Bakers Street providing inspiration to testers like ( not a great tester ) me , Robert Sabourin (great tester) and many other great testers, observes patterns and structure of people whom he suspect to be criminals and tracks down the criminal based on the pattern and structure of crime.

I observe a pattern and structure through the bugs that arise from a developer's code. It has helped to build my intuition and hence when I get a release with changes made by a specific developer, I look for those patterns and structure, which has been handy sometimes to find important problems, rapidly.

I felt it's a good idea to inform the developer, my observation about the pattern and structure of the bugs that arises of his code and did it in a polite way ( developers aren't criminals, remember).

Outcome:

3.a. He said, "Thank you! I now know where to work on and develop my development skills."

3.b. Our relationship got stronger.

3.c. I am convinced that good testers can help developers to develop their development skills.
(For those developers looking at this post, I hope you got a reason why you should lend your hand when we want to shake hand with you, for your own benefit. We love shaking hands with anyone who could help us better our testing and you are important to us)

Meta cognition helps me develop my testing skills and testing activity and I am happy that it helped others too.


-- Pradeep Soundararajan - pradeep.srajan@gmail.com - +91-98451-76817

"Pradeep's first language is not English--his first language appears to be testing." -- Michael Bolton

Shore, Offshore!

I love meeting testers and I also love hearing their stories. A conference is one such place where we get to meet a lot of testers and talk about a variety of topics. I understand that I might not be able to work on all technologies and products in this life and also attend all conferences that are happening. A meet with a tester, who works on a product different than what I work, brings me joy of learning. This also helps me to clear traps right away if I get into one such project in future. It has helped me come out with new ideas, learn contexts that I haven't been exposed so far, learn how other testers solve or get into problems.

My curiosity to listen to all those stories makes me attend or speak at a testing conference in India. An year witnesses a couple of conferences and this leaves me craving for more stories. I have been fortunate enough to meet at least one new tester every 2 weekends. Most of them are the one's who have came across my blog and expressed interest to meet me.

Samana ( name changed ) is a tester who works for a company whose product focus is health care. While the development team is in Chicago, testing happens offshore in their Bengalooru ( earlier Bangalore ) office.

Here are some of the points that I felt important and captured from the story I heard from her -

1. The development team from Chicago sends an e-mail seeking/conveying an important information at mid-night India time, where testers in India are catching bed bugs. The time Indian testers come back and look into the e-mail, the developers in Chicago run a status in their IM , "We sleep too". Once the manager in India or US realizes the importance of the information, they setup a teleconference, usually at mid night India time. All this results in a delay of information for the tester and hence delays the progress of testing and the project.

2. "It works for me" - A statement that tests a tester, if conveyed by a developer, who is available locally, is safer than receiving it as an e-mail from a developer in Chicago. Samana in Bengalooru, claimed to receive such e-mails pretty often from developers in Chicago and which takes her a lot of e-mail interactions or a couple of teleconferences. The manager then takes a decision and conveys "We have spent a lot of time on this, lets find more bugs instead".

3. Information that the testers in Bengalooru feel important are put at a low priority by the team in Chicago and vice-versa happens too.

As a consulting tester, if I were consulting such an organization facing similar issues who intend to smoothen things, here is my answer to the client : [ if he happens to look at this post ] ( assuming whatever Samana told is happening in the company )

1. I infer from what I have heard that a lot of time is being spent by testers seeking information than on testing, hence I would think of an idea of having a video conference with the entire team on both ends of the world. Before the video conference, each tester and developer will be asked to prepare a list of questions they might want to ask anyone in the conference. If the developers and testers show interest in the first video conference session, more such sessions can be held. It is very important for a tester or a developer to know the questions that their co-workers have. The video sessions are recorded and are viewed offline too, by both ends.
2. If a tester or developer asks an important question that should have been asked earlier for the benefit of the project, it is an alarm that there might be more important questions to ask. I generally recommend testers to use "cidtestdsfdpotcrusspicstmplfdsfscura" to ask questions. "cidtestdsfdpotcrusspicstmplfdsfscura" is James Bach and Michael Bolton's mnemonic to remember 36 important heuristics that helps a tester to ask questions, think of test ideas and remember to test those things that matter the most to the customer. If you want to know more about them, I recommend this screen saver ( because I developed it and I agree it hangs on some PC's) which claims to help testers remember and apply heuristics those heuristics. For those who fear to run the screen saver there is www.satisfice.com/rst.pdf
   
3. It is very important as a tester to generate more time to test by avoiding traps and to provide quality related information to help management take informed decisions. Thinking of cost v/s value is equally important. On finding a blocking issue, I would continue to explore the program and not just wait for a fix. Currently, I observe that when a tester in India finds a blocking issue at around 12 PM IST, he waits for the fix after sending an e-mail to the development team stationed at North America. The developers to get back to work, read the e-mail, get convinced to fix the issue and providing a fix takes some time. The tester spends at least one and a half days waiting for the fix. As a tester who has seen the power of exploration, I would spend my time learning other areas of the program that appears to work and might be worth learning, exploring and testing. Other testers who get inspired by me doing exploratory work despite having found a blocking issue, are welcome to join me to test. Pair testing is a bonus!
4. All testers and developers are encouraged to put questions and replies to them, in a forum that is accessible by all team members, all time. Well, you might think about why a discussion forum/wiki when e-mails are there. It is very important to share learnings across the team. As a rapid tester, I would look for such information and knowledge shared by other members of the project while I test. It would be better to have a dedicated forum to it. It does not cost much to the company.Look, I am still thinking of cost v/s value.
5. To know more, I suggest you hire me :)
   

Here is a funny fact about offshore: "shore" in Hindi language ( the national language of India ) means "chaos" in a specific context and "noise" in all other contexts, maybe.

-- Pradeep Soundararajan - pradeep.srajan@gmail.com - +91-98451-76817

"Pradeep's first language is not English--his first language appears to be testing." -- Michael Bolton