Ants solve problems that testers struggle to!

Ants can go into corners of tables and chair, which we humans might not be able to.
Ants can travel to any country without a passport or Visa (if they manage to slip into someone's baggage).
Ants can live anywhere and yet not pay rent or property tax.
Ants can eat junk food forever and live happily.

Doesn't all of them sound so obvious?

So, here is something that might not be so obvious about ants... Little creatures that we commonly refer to as ants have solved a problem that many testers today struggle to.

Have you heard a tester say, "I haven't tested this before / this is too complex / I don't know how to start testing it".

The important thing to note is that we might have heard it from our own mouth or heart and sometimes from others, too.

Here are some experiments that I did with ants to see how they respond to complexity:

Experiment 1

I took an ounce of sugar, placed it near a colony of ants and observed what happened to the sugar I placed after a while.

My experiment resulted in each ant carrying a crystal of sugar and moved them to their nest. Sugar is all gone!

Experiment 2

I placed a cake of size approximately 1000 times bigger than an ant in the same place and observed what happened to the cake.

This experiment resulted in each ant breaking the huge cake into smaller fragments and moved it to their nest bit by bit. Cake is all gone!

Experiment 3

I put a piece of solidified sugar candy near the same colony, which was hard to break for an ant.

This experiment resulted in ants trying to break the candy to smaller segments, but probably the smart ants realized it to be complex than their earlier two assignments I gave them and then they all co-ordinated together and carried the candy to their nest. Candy is all gone!

I bet I could place a mammoth of food for them and they, without bothering about the complexity of it, would try moving it to their nest or create more nests and colonies to accomodate it or work a strategy to get it to their nest or much it as much as they can till the mammoth lies there...

Ben Simo, a wonderful tester you might already know, recently wrote a post titled Solving Intractable Problems and ended it beautifully by saying, "Start with what you recognize" - which I now think is what ants do instead of saying, "That food(work) is not for us, it is for bigger (skilled) ants"

After having done these experiments I was ashamed of my behavior of hesitating to test a product (which I did a couple of years ago) just because something appeared to be too complex or I thought I didn't know about the product or technology.

No, I said, *I* was ashamed and I am not going to ask if you were ashamed because you might have not done that.

After all they are ants and they don't have the super brains we have and lets ignore them folks and continue to live as happy as we are, complaining that things are complex.

Silly ants, they don't even know they are dealing with complexity. I think they should be ashamed of it.


Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

Jony Jony, Yes Papa! Following Process, Yes Papa! Telling Lies, Ha ha ha!

I am 100% sure that this article would make no difference to the world because there have been better insightful articles than this about the topic that I have started to write, which didn't make much difference to the part of world I think I am living in.

I feel it is important for you to ask yourself, "Why would I want to read an article that the author is certain that it wouldn't make things around me better?' because by asking that question and continuing reading ensures that you are wasting your time because you chose to.

I conducted my public workshop on December 1st through Edista Testing - a QAI venture in Bangalore on December 1st. A couple of months ago, I had expressed my dream to go around places in India other than Bangalore and conduct my workshop on human skills of testing titled Exercises for a Testers mind - A Rapid Software Testing Approach and the dream is coming true as Edista plans to bring this workshop to your city wherever you are in India. Do not worry about the cost as long as your company can sponsor you for a day.

I challenge testing minds and I learn from them and some of the curious minds who attend the workshop largely benefit from the workshop. All audience are thrilled about the things they learn from the workshop but what makes them sad is that they have to go back and follow the process their company mandates them to follow - which at the end of the workshop they know that it doesn't add as much value as they witnessed the value that Rapid Testing adds.

How do you think they witnessed, the value that Rapid Testing adds V/S the value that their process ( IXX, CXX - Level X, SICK6 SXXXX, XXXXX, Centre of Excellence, Test Factory) adds?

This time I felt terribly challenged at the question of process and I revealed something that shocked the audience and were not willing to pose further challenge. Its exactly an year old secret that was lying in my inbox and I had shared it with very few.

Rapid Testers stand up to scrutiny and so I stand up to scrutiny in case the following information you might read, appears to be an exaggarated or made up to prove a point. It might appear so because those who dwell with those processes can never achieve it and it is close to impossible for one who believes in those to believe the following.

Here is an e-mail that I received last December from my Supervisor from a large Products + Services company of India on the last day of my job at that company.

---- Forwarded by Pradeep Soundararajan on 12/27/2006 04:29 PM -----
All the best, Pradeep.

There are learnings for all of us from the way Pradeep has conducted himself in this tenure in the team. The confidence he has shown and willingness to help others and constantly exploring for new ideas are some of the highlights. Fortunately I was also part of the team which Pradeep was associated.

One more thing I would wish to share with you all is that, he was handling XXXX (product name masked) releases for XXXX (A multi billion dollar customer name masked - who also had a test team at his end who tested the releases we made before they released to their customers ) and with proud I can say that there isn't any bug which customer found apart from what we or Pradeep found here.

On behalf of the team and on a personal note I wish him all the best in all his future endeavour .

Regards
XXXXXXXXXXXX ( Supervisor's name masked )

__ end of e-mail excerpt __

Some very important points to think and remember:

• To remind you, this company too, is one such who believed in the above mentioned process till I helped at least some teams realize that they could achieve bigger success if they could come out of the trap they fell into and add more value to customers. No customer would say - I don't want you to add more value but I am paying you to follow XXXX process. If a customer says that, either the customer needs to be educated on testing or it is a customer who deserve to be off the business list unless the customer is willing to pay a huge price.
• Some of you might think this post as my self marketing and might fail to learn some important lessons that your customer might want you to learn. Also if I wanted to use the above as my marketing, I wouldn't have waited to reveal it an year later.
  
• Some of you might think this happened somewhere too far away from India, which is not true, because this happened in Bangalore, India.
• Some of you might think I did *complete* testing but I admit that I know no one can completely test anything, so I did not do complete testing.
• It was no one man Pradeep show, it was a team effort and it was achieved because I practiced the skills that James Bach and Michael Bolton helped me gain on the product I tested with the skills that I already claimed to have + the skills of the team + Exploratory Testing mixed with very little scripted testing.
• This achievement for the company, the team and me didn't happen because we intended that to happen at the start of the project BUT we had realistic goal as a test team "To find important problems, quickly, and gather as much information as possible through our SKILLS and present them in a useful manner to help the management take informed better decision" AND NO STUPID GOAL SUCH AS "LETS MAKE A BUG FREE PRODUCT".
• By the customer not finding any bugs other than what we found, although there was a test team at his end, doesn't say that the product was bug free. What customers looked at is value for the money he paid us, and I think he was sure, as the project progressed that he was getting a bonus. At least it helped him understand that he had to hire a better test team than us to find bugs out of what we had found.
• It is hard for me to know what is the state of the product now but I can safely say that the 8 month duration I stayed there, there was nothing that our customer or ever his customer reported on the releases we made that we didn't know.
• I'd like to add another important point that in order to achieve what you read above, I and the team had to break certain things that the process mandated to achieve it.
  

Don't ask your management or customers to read this post because both of them might start to demand more from you, which might take away your coziness you have been enjoying in testing with the process you are asked to follow. In case you are curious to share with them, be prepared to learn and practice human skills of testing and better insight into testing, out of which some of them are taught by James Bach and Michael Bolton's Rapid Software Testing and Cem Kaner and James Bach's BBST courses.

"I would say that a process is the way things happen. The Earth in orbit around the Sun is a process. In that sense, yes Rapid Testing is a process.

What Rapid Testing isn't is a set of instructions to be followed without understanding. It is not a collection of physical behaviors. It isn't even really a set of techniques, although it does feature some of those. To say
it's a skill set and mindset is to locate RST within the mind of a tester. It's a process of making sense of testing problems and reacting to them differently, as the situation demands." -- James Bach


"One of the hallmarks of Rapid Testing is that your work can suck less. The pointy-haired bosses can tell you what to do to some degree, but they can't supervise you every minute of every day, and they can't tell you how to think. In the "free" time that you have--those little micromoments of disposable time, for which you won't be punished because they can't watch you every moment--you can perform a quicktest, find a bug, write another line of the test tool you're working on, sneak a look at the specification you managed to photocopy, check in on your mission, befriend a developer, have a chat with another tester about where the bugs might be, cover a product just a little more deeply with just one more test... And after you've leaked a little of what you've discovered and have a few successes under your belt, maybe you can start to train your manager into expecting nuggets like that." -- Michael Bolton

Here is another evidence of high value addition that Rapid Software Testing produced to Michael Bolton's client

Here is one of the great and very insightful quote I have read about achieving the mission, "Who cares if you followed the instructions if it doesn't work when you're done?" - Scott Barber's Dad

All I have done in this post is to complicate that quote in many words which the wise man said it in one sentence. I apologize for that.

-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

Second time, a company in India wants to hire testers in a non traditional way

What is the company looking for?

As a Test Manager of the company, I am looking for 3 testers, each of whom has spent at least 2 to 5 years testing and learning diversified things in testing. I want to challenge the tester in a permanent position in the company I work for, to solve complex software testing problems, whose main focus would be to question testability and supportability of products and write tools to augment testing activity.

Interview

The interview would typically be a telephonic followed by one full day at office premises (probably a weekend) in which you would be given a mission or different missions to achieve by the end of the day. You would face questions based on your testing activity at the end of the day.

I am not listing the skills you need to have but I know whether I should call you for an interview or not through:

1. Write 2-3 pages about your testing experiences so far. If you reveal any confidential information, although you might be too good, I am not taking the risk of calling you for an interview.
2. You may want to attach your CV or anything you think might interest me to call you.
   
3. Fake experiences would be reported to police, so don't risk yourself.
4. Don't mention, even if you have certification in software testing, because it just doesn't help/ better any chances nor worsens. I intend to hire you for your skills of testing and not your certificate that plenty people found it easy to clear.
   

If you are a fresher, Test anything over web and send me your report. I might still be interested to foster you.

e-mail me your reports to testwithpradeep@gmail.com

Here are some highlights of working with me:

1. All testers who report to me have been enjoying freedom, which is very important for testers.
2. All testers who report to me haven't been asked to do documentation that's wasteful or for the purpose of documenting to follow a process.
3. All testers who report to me have got a chance to be questioned on their work quality and some have been rewarded once they practice the changes suggested and also see a value in doing those changes.
4. At least one tester who reports to me started to blog about her testing activity and the thought process that went through to find some bugs ( without revealing the confidential information, of course)
5. All testers who work with me have had freedom to challenge me (without bothering if I am their Manager or not) or my ideas I propose to test without bothering if that would affect their credibility with me provided they are open to learning and unlearning.
   

If all above looks tough to you and don't want to put in that much of hard work to get a challenging testing role, Yahoo, my filter works.

Here are some traditional stuff:

1. Your designation might be a Senior Test Engineer or Test Lead who reports to me (but don't bother too much about that right away).
2. Your pay is decided by the budget allocated for these positions which is in par with industry standards calculated based on some formulas that I am not aware of. Post observing your performance, your pay is not decided by any formula but solely your performance and the company's performance in market.
   
3. You will be required to join ASAP or within 30 days of the date of offer.
4. The work location would be Bangalore.
5. The 10 year old US based medium sized company I work for respects and value testing, and post me coming in, I see more recognition towards testing given by the senior management.
6. There might be some traveling opportunities in Q3 2008 but no guarantee and don't get attracted just because there might be a traveling opportunity.
7. You may be a tester from any domain as long as you don't have a mental block to learn new domains and technologies.
8. Send in your entries before others steal your chance.
   

The good news for those who are excited about this is, I am sure very few people would dare to compete and hence the competition wouldn't be that fierce. So the more excited and curious you are when you read this, the more likely you might be hired.

So, who are those 3 testers among you who would get this unique opportunity that probably other Indian companies might not offer.

It takes courage to challenge and skills to tackle the challenge. I am calling the skilled and courageous to work with me. Get in touch through testwithpradeep@gmail.com

For those of you who want to know what traditionally companies ask for, hit MonsterIndia or Naukri websites and search for tester job openings. Not to my knowledge anyone asks for skills of testing from a tester, instead would focus on tools knowledge or horribly trivialize manual testing and process knowledge.

Hey look, at least some part of Indian testing is changing with more focus towards human skills! Are you left behind?

You might want to know, when was the first time a company in India wanted to hire a tester by non traditional ways... Simple, when the company I work for hired Pradeep Soundararajan ( that's me ) as a Test Manager at his age of 26 and helped him become the youngest Test Manager of India.

-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

How to show product quality? - (Uncensored Version)

E go U go I go of U and I

I have no control over your thought process to restrict you to not read the title as Ego You Go and I go of testers.

Here is what I think about my ego:

• I am egoistic but not at contexts and situations where the ego could kill the possibility of me doing a good testing.
• I am not egoistic because I am so curious that I don't care from whom I learn something that can help me do a good testing.

Which of the above two statements could be true in your case, too?

The passion to become good at the craft we are living in makes us better person, too, and the evidence is from my incomplete research on ego and testers.

In my experience, so far, I have had an opportunity to work with testers from various backgrounds (education, culture, native place, language, the way they were brought up ...) , experience ( in terms of number of years , non testing field experience ), skills ( whatever they think their skills are, whatever I think their skills are), knowledge (domain, craft specific ), interests ( curious to explore testing or curious to explore something else), passion (testing or money or both [ certification - if you like it] ) ... and infer that one of the most common thing amidst this diversity is ego.

People (who think they don't have ego) think those who have ego are the ones who are bad professionals. I ( who is sure that I have ego ) think it is not that bad for people to be egoistic as long as they achieve the mission they have in hand without spoiling opportunities to succeed in future missions with the same team.

I think I have not anything different and I am happy to have identified it.

I am going to discuss 3 cases ( the most common and uncommon ones, in my opinion ) that can help me ( or not help you) to understand what I inferred from what I witnessed, experienced, heard and saw.

Case 1: From Lead to Seed

A senior tester (by designation) got promoted to a Test Lead and thought he'd be no longer expected to execute tests. He is moved to a new product based on a requirement of a Test Lead and finds himself in tough situations where people who report to him aren't respecting his views. What he fails to identify is the need to build credibility by executing tests and understanding the product.

The ego of being a test lead and yet not respected by people who report to him ends up in clashes about ideas to proceed with testing. The manager identifies that it would be a good idea for him to learn the product, execute tests for a while, understand the testing complexity and challenges and then play a role of a Test Lead ( as per what he thinks ) ends up in he taking up test execution. During the process of test execution, the ego is still alive and he is hesitant to ask questions that he thinks his team members would laugh at and finally ends up in not knowing the product well and failing to execute tests in a manner that someone thought it as a right way.

On the other side, the team members who report to him do have an ego that built up during the process of knowing that their team lead knows little about what they are doing.

So the Lead and the team members never get a chance to respect each other. Not to forget is a point that there are similar ego issues between the team members.

I guess that leads to bad testing!

Case 2: Buddy testing and then Bloody testing

A company enjoyed having 2 senior testers (senior by designation and lets call them Shyam and Jagan) who were passionate about testing and their work competed against each other's work output and was a healthy competition, of course. Shyam and Jagan worked on the same product but for different customers. Both of them were known to be good at meeting the mission in hand and the important point to note is: both were thick good friends for over 3 years.

Unfortunately, one fine day Shyam's work is applauded by the management. This act of appreciation hit Jagan hard enough to start building up an ego with Shyam. Poor Shyam, not being aware of this ego that Jagan is building cracks jokes ( as both used to ) on Jagan's work and this hits him more hard.

Shyam who cared for his friend Jagan was left disappointed when he did come to know about the multi storied ego that was building. Shyam eventually found it tough to continue working as he too started building his own version of ego. The ego got translated into an unhealthy competition that ended Jagan to look out for a job where he feels safe to work without such unhealthy competition. Shyam and Jagan still thought alike as they used to and both ended up looking for a job without each other's knowledge.

Both quit the company and moved to different ones more or less at the same time without realizing. Here comes the crux of the story: Shyam and Jagan never felt happy with their work thereafter despite working away from each other because what motivated them to succeed in the past was the healthy competition.

I guess that lead to bad testing - for Shyam, Jagan and to the company they earlier worked together.


All it takes is one second...

It takes just one second to feel egoistic and not do something that you too are aware should be done but that one second might result in making you and others around you as bad testers.

It takes one second for those who stole my posts to admit they stole but makes them feel better forever that I appreciated them.

It takes one second to feel egoistic ....
Case 3: From Manager to Damager

Wait a second, let me write the Case 3 a little later because, I got a mail from a team member who thinks he is too smart because he was appreciated for finding a lot of bugs and is a better tester than me. He is challenging my decision. How can he do that when he is reporting to me? I am going to fire him right away and shall update this post later.


-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

Some good testers don't blog and so I think the testing community is unfortunate that they have limited opportunities to learn from them. Some bad testers steal others post and so I think the testing community is unfortunate to fear the fact of why some good testers don't blog. Willingness to learn is a skill that a tester *must* possess in my opinion - which also helps in having a lack of ego. I guess that's how good testing begins.

Test Case Passed! Who cares?

This will take away at least 8 minutes and 24 seconds of your time, so please be careful if you'd like to spend your time on a thing that potentially has a risk of not yielding any good thing for you as a tester. Maybe you might want to continue executing test cases instead of going through this. Click on the image to waste 8 minutes and 24 seconds. You are lucky if you don't have a MS Powerpoint or Open Office suite or anything of that sort because without that you can't waste 8 minute and 24 seconds that I am repeatedly mentioning.





-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

The most challenging software testing quiz online

This quiz created by me challenges a tester to answer several common and uncommon questions. At the end those who finish the quiz get to know what prize they win. ( which means, there are a lot of prizes to be won)

Last time I announced I would give free books - Lessons Learned in Software Testing and I did give it to those testers who proved to me that they deserved it by working on an exercise I gave them. This time I am keeping it as a secret because those who finish the quiz will get to know their prize when they see their performance and results. I have some questions that are easy, some which are moderate and some that only experts can crack - so whoever you are - you have a challenge.

Update me your score because if your score is more than other testers who have taken this quiz then you have a chance to win the many hundred dollars that I plan to give as a bumper prize. So here is the link to The Most Challenging Software Testing Quiz (I could ever think of creating)

Good luck!

Update: 12th October 1300 IST: The quiz is updated with HTML formatting and looks more great to my eyes. Thanks to Adam Goucher for his suggestions. 3 more very challenging questions are added. So you might want to re-take and check your score. If there is any betterment of your score update me so that you dont miss the grand prize.

Update: 12th October 2345 IST: If you dont see your comment for this post it is because I felt your comment contained some clue about the answers which might distract new people taking the quiz. In case you want to blog about this quiz please make sure you don't give the answers or let the people know the answers or experience as they might lose the excitement and opportunity to learn.


-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

Tester Tested! coming soon to your city

I offered a public class recently and there were testers from Thought Works, Philips, IBM, McAfee, MarLabs, Mphasis, Mopat Solutions ... (other names that I can't recall) At the end of the session each of them looked thrilled and excited. We had hours of discussion even after the session officially ended and that is a clue to me about the excitement and joy of learning they had.

Now, all my public classes have been in Bangalore but that's not the only destination where there are testers. India is wide spread and I have decided to travel different places, which also helps me take a break by meeting different people and visiting new places.

More than a dozen testers from Chennai, Mumbai, Pune, and Hyderabad have been in touch with me over e-mails and looking at my stats I am sure there are at least more than a hundred testers from each of these places who read my blog regularly. I am sure that each one of you who have been interacting with me also know couple of testers whom you think might be interested to attend such a session.

In case you are interested to have the testing skills workshop in your city, please do get in touch with me by writing an e-mail to pradeep.srajan@gmail.com with subject line "Workshop - ( your city name). I shall share the contacts of other testers from your place who have been in touch with me, we could discuss over e-mail and get the workshop up in your city, too.

Lalit Patil, a tester from Mumbai did organize one such session of mine in FEAST, Indian Institute of Technology a couple of months ago.

This intention of mine to travel different places is not to come back from each city with loads of money but with an intention to benefit testers who are away from the reach of my Bangalore public workshops. So that doesn't mean its free! Based on the number of testers who are interested there would be a cost each has to incur to support my travel and other expenses.

Despite my workshops always have been in Bangalore, so far, I am very happy that there were 4 testers who traveled from far away cities to attend it. One came from Thailand, One was from Hyderabad and the other two were from Chennai.

I dont expect great things to happen after this post and I also wouldn't be too surprised if nothing happens. I am just hopeful that testers from places other than Bangalore would be as interested as my fellow Bangaloreans are.

Hope is an important thing I rely on and so I hope at least there would be at least one other city in India that is as good as Bangalore.


-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

Pradeep fails BBST & continues to seek the Holy Grail

Yesterday I spoke to Jon Joseph from Pondicherry, Tamil Nadu, India. He has at least 4 times more experience than I. He had owned a software development company prior to 2002 and now works as a Senior Test Engineer in a company that develops e-publishing software. He will be coming down to Bangalore to attend my upcoming session on 29th September.

It was a great experience to listen to his appreciation of my blog and the impact this blog has made to his life. He having developed software as a start up and has had experience as a Lead for Java based products switched to testing after reading my blog (not because I convey that message).

That's not my achievement, it's his own but maybe what I helped him and he said; "my work and thoughts have got a lot better and your blog is something that I worship".

Well, if that seems too hard for you to believe here is what Michael Bolton said last week: If a test passes in a forest, and no one sees it... and James Bach quoted that line that Michael liked from my blog in Nationwide Insurance Conference in the United States, the same day.

That makes Pradeep a great tester!

Now, here are things that helped Pradeep (that's me) realize he isn't a great tester and Pradeep also wanted to share it with his readers because -- after listening to people who have been impacted by his passion, coaching and blogging, he felt responsible to let all of them know that I fail and I struggle just as they do.

I took up the BBST Foundations online course offered by Dr Cem Kaner, Scott Barber and Jon Hagar from Association for Software Testing in the United States of America. I miserably failed the course, in my opinion, and thankfully the reviewers had the same opinion.

There were bunch of things that contributed to my failure: lack of time, improper time at which I worked the course, over confidence, lack of humility, under estimating the complexity, different method of teaching that was new to me, blindness towards the quality of my answers, lack of math skills, frustration of not performing to my expectation mid way through the course, a sense of embarrassment after looking at others answers, ...

but that doesn't mean I did not learn anything from the course. I think I had a very different and fantastic learning. I also learnt a lot more about testing that I did not know. I was glad that I was honest through the course and I admitted what I did not know and also admitted that I forgot a few things during the exams and exercises of the course, which fetched appreciation from another student who reviewed my answers.

There was another Indian on the course who did perform very well and I am very, very happy about that. My close friend Ben Simo too performed fantastic and would be the person who teaches the course the next time I take it and he deserves it.

I was worried if James Bach and Michael Bolton might be disappointed with my result but I was delighted to know they weren't. They helped me understand a lot more and James said, "I see this as a learning process and would be great for your teaching, to help your students know that you too struggled and faced the pain, which can make them happy that they aren't the alone in facing such problems" and then said, "I would be disappointed if you do not take this up again and pass through it".

I also had another worry: fear of losing credibility with Dr Cem Kaner and Scott Barber, which I have not dared to ask and it is better not to know certain things. However, I have great respect for them and their time and I thankful to everyone who spends time for my learning.

I would be curious to know what you learned from this post?

Here are some things that I decided to do:

I am going to put this failure of mine in the presentation that I am doing this weekend at Bangalore. It is important that people know that I talk about my failure when I introduce myself and helps me in remembering that I am not a great tester yet.

I might not be willing to approve any more comments on my blog that just appreciates me or the post that I write. I am young and I am not wise yet to take such an appreciation not deter my growth. Your true appreciation would be when you let me know that some ideas or all ideas helped you do better testing just as Jon Joseph. He has been my blog reader for more than an year and has never commented but got in touch with me to say my blog has impacted the way he does and think about testing over e-mail or phone.

I am sure this might make my competitors (if any) feel stronger and I don't mind that. All I want to do is to become a good tester.

I wanted to post this on my blog that I can visit any day in future to help me realize my true self.

I also am going to be a little away from testing for a couple of months because one thing that I need to do is to take a break. I haven't taken a break in the last 2 years, which was another contributor of my failure. Too much of anything is bad and to keep myself alive in this industry, I have to be a little away from it for sometime. That doesn't mean I wont blog but it means I will not do a lot of things that you might or might not know for sometime. That also doesn't mean you should not get in touch with me for help. I love to help, especially after knowing that I am not a great tester yet.

Why do you think you are seeing words, "great tester", too often in this post?

It is because I thought I was an upcoming one such and also because I discovered that it is too far away than what I imagined and here is a post to

Don't forget an important message that this post is saying: Pradeep fails + be careful if you are following his ideas and suggestions.

It is also important to note that I don't intend to be a person who can never fail but I am worried about the reasons of the failure. There were things under my control which I should have taken care!

Here is my view of perfection: It is an illusion or lack of experiments that can help in discovering failure.

I think I forgot to tell you that becoming a great tester is like seeking the Holy Grail and I wish I am not as the knights of round table of Camelot to get lost in the quest. Jon Joseph said he shall pray for me and I am sure there would be a handful to do that along with him.

No training course, to my knowledge in testing offered anywhere in India can teach wonderful things that James and Michael's Rapid Software Testing and James Bach and Cem Kaner's Black Box Software Testing (BBST) can teach but I am optimistic about my workshops as they are reflections of these courses.

Time for me to appreciate things as how they are without questioning!

-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

Notes from spying test experts

This is a top secret post and be very careful with the information. I am not sure if I can expose my notes to my dear blog readers but I am taking a risk of doing it.

There are some secrets of test experts that not many know. I had a mission sometime back to spy about how test experts actually find many important problems, quickly.

Many people think ( that included me, too) that Test Experts do lot more tests and have more fantastic test ideas and that's why they find many important problems, quickly.

I was hoping that there is more information hiding than what is visible about test experts and spying helped to uncover those hidden secrets.

This post is all about the secrets that I found spying test experts and the secrets of how they find many bugs?

You can trust me about the information to an extent that I and many other testers have been practicing the secrets that has resulted to our success of finding many important problems, quickly.


They just do one test to find many bugs!

Now, I am sure you don't want to believe me because my finding says that they do just one test to find many bugs. I am sure you have seen testers finding one bug per tests that find a bug and that makes you not believe this information but... you must understand that the secrets are always unbelievable.

You can feel safe after knowing a fact that I too didn't trust the secret of one test finding many bugs but my spying mission was to find out more granular details about it.

Looking more carefully into it, you might discover that it is not a test that finds a bug but it is a human that finds a bug and a test plays a role in helping the human find it. So there is something with humans that is helping to find bugs and not completely with the tests.

When I collected this much of information over months of spying, I was invited to be a part of the round table conference of experts as I had posed myself as a test expert from India (I knew I wasn't a test expert and even today I am too conscious that I am not one such) but you know... I am a spy and had to pose that way.

Over the round table conference, test experts started discussion about ORACLES* and I didn't know their terminology and just took notes. That evening, when I returned to my hotel, I was trying to connect ORACLES and the spying mission I had in hand.

* Oracles - principle or mechanism by which we (humans) identify problems

I was perhaps lucky that James Bach and Michael Bolton were staying in the same hotel that I was put up and we caught up at the dinner table.

I had an idea that I hope it worked. I was hoping that James Bach is a kind of person who would spill off the secrets in a context to prove me wrong and help me learn the secrets if I talked nonsense about ORACLES, because his passion to the craft of software testing is something that I am trying to match. Michael Bolton, the Birbal of North American software testing was a person whom I had to handle very carefully as he is more likely to identify me as a spy. At the end, I assumed that I was able to outsmart Michael in not letting him know that I am spy.

Going back to the hotel room, I started writing my discoveries about the secrets of test experts and the granular details of how they find important problems,quickly.

Before I publish a report to end the spying mission, I was sure that I had to practice the details I collected. I did practice and was excited that those ideas really worked and I found more bugs by executing one test.

Why many testers might not be able to practice the secrets that I am unlocking here is because they have a fixed expected result that is derived from a specification document that the tester thinks is The Holy Bible for the project.

Specification Document - is one single oracle and hence you might find one bug per test you execute.

The important thing is experts define a bug as "anything that threatens the value of the product" (-- James Bach)

Here are a list of Oracles that experts use with every test they do:

Consistency with the Image: When I execute a test, I try comparing and contrasting it with the image that my company or stake holders have been projecting about the product or the company.

For instance, if my company has an image in the market as people who produce software whose performance is good, and I execute a test whose documented expected result is "This functionality should work", I ask question, "Well it works but didn't it take too long to perform the operation?" and then I find a bug and say, "Although this operation goes through the time it took to complete the operation exceeds beyond the image the market has about us"

Consistency with Similar Product(s): When I execute a test the functionality might work as expected but I ask a question, "Well it works but doesn't it seem to perform in a way that users who are used to similar products might expect it to happen?" and then I find an important problem, quickly.

Consistency within the Product: When I execute a test that appears to have passed, I ask a question, "Well it works but doesn't it work in a different way than other areas of the same product?" and then I find an important problem, quickly.

Consistency with Claims: Marketing personnel and my manager are making certain claims about the product. When I execute a test and the test appears to have passed, I ask a question, "Well it works but does the way it works go against the claim that they make?" and then I find a bug.

Consistency with Statutes: When I execute a test that appears to have passed, I ask a question, "Well it works but does the way it works go against a law that an organization or a certifying authority might have?" and then I find a bug.

Consistency with User's Expectation: When I execute a test that appears to have passed, I ask a question, "Well it works but does it work in a way that the users whom I am aware of might not want it to happen?" and then I find a bug.

Consistency with History: When I execute a test that appears to have passed, I ask a question, "Well it works but does it work in the way the previous releases of this product work?" and then I find a bug.

While writing this post, I got an e-mail from James and Michael that reads...

Dear Pradeep,

We knew that you were spying us for a long time. We also saw the way in which you took notes, asked questions and drew inferences from what you could capture and that impressed us to help you learn more about testing because those are some important skills that a tester needs to have, to add good value for the cost customers pay for. We consider to hire you and we recommend you to quit spying profession and take up testing where you might get more laurels for your skills. Here is a link to know more about more secrets : www.satisfice.com/rst.pdf

Good luck!

-- James Bach & Michael Bolton

I was excited and I did quit spying, to take up testing as a full time activity. I thought I shouldn't post this in my blog because I didn't want those secrets to be given away for free and saved a draft of this post. I am afraid if Blogger has a bug that publishes drafts that are not intended to be published.


-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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


Update : Michael Bolton, blessed me with a post on his blog for this article of mine. I was jumping in joy for at least half an hour reading that and I am pleased to share it with you: http://www.developsense.com/2007/09/if-test-passes-in-forest-and-no-one.html

Mother Nature - A teacher of all good testers

When I started to test, I wasn't aware that I entered a fantastic field that demands me to look at other professions to do a good job as a tester. A little later I realized that people in a specific profession have lots to learn from other professions to perform better at what they are doing.

Everyone, in my opinion does that but the question is: How many do it consciously?

Don't worry, you aren't left behind and here is your opportunity to unlock what you could learn from other professions. Here is an example of how Michael Bolton and Ben Simo talked about "How doctors think and the learning of a tester from that thought process" . During Michael's previous visit to India, we did talk about how his experience of cooking and theater that helped him in his testing and I was very glad to hear those stories.

I intend to pull out my notes of how people in different professions think that can help testers in their testing activity:


Doctors


I had mentioned this earlier and I would like to re-iterate. Doctors ask a lot of questions as a part of treating you. When a patient says "I am having a back pain", I have observed doctors asking questions about the hand and legs and they carefully observe emotions of the patient when they try to press the back, different places in leg and hands.

Software and human body are very complex systems. The "back pain" might be a symptom of a bigger problem and hence doctors ask questions about other parts of the body. So, as a tester if I encounter a bug, I get to think that this bug might be a symptom of another big bug that is hiding and ask questions that help me figure out the big bug.

When a patient says, "stomach ache", I have observed doctors prescribe blood tests and various other tests to take an informed decision. The management needs as good information as possible to take better informed decisions and testers need to supply the information. By prescribing blood and other tests, the doctors are looking for coverage and so, we testers need to look for coverage than to find xxxxxx number of functionality bugs (unless that is the mission).

When a patient is in a critical state and needs to be operated, there are diversified set of doctors who are in the operation theater. For instance, an Anesthesia Specialist, General Surgeon, Neuro Surgeon, Heart Specialist... and NOT all General Surgeons or all Neuro Surgeons do the job. That is a fantastic example of diversity and value addition to the operation's success. A testing team needs to be diversified. Not all testers who know to run tools like QTP, WR, LR ( toolsmith's I mean ) can add value to the project and successfully achieve the mission. Look at my FAQ's for more information on diversity of testing teams and its benefits.


The Indian cobbler ( I don't know of any other country cobblers)


An expensive shoe that we purchase might have been manufactured by a top company with state of the art machines but when it is torn or needs a fix for the sole, we do not go the manufacturing unit but to a cobbler nearby.

The Indian cobbler is a pretty simple guy. He uses the tools that are not state of the art but yet does a fantastic job whenever I or my friends have gone to him to get a problem fixed. He doesn't intend to use a tool because other cobblers think it is state of the art because it doesn't suit his context. Many companies buy tools from vendors who market it as state of the art, and later discover that it isn't suiting their context well but force the testers to use the tool to see some value of the money spent on it and lose the value that could have actually been delivered (if the tools were not put to use).

There are some cobblers who move on road and they dont carry tools that are hard to carry or need electricity to operate and yet complete the mission assigned to them. They do a manual activity and harness the potential in the tools that they carry to maximum extent. No testing is completely manual and no testing is completely automated. Those who think they are testing something completely manual are as much wrong as those who think their testing is completely automated. Those testers who know to carry the tools that suit their context are smarter and will add great value as compared to those testers who carry tools with them because someone said "That's the future".


Police ( What movies has shown me)


Catching criminals is as interesting and challenging as catching bugs. Police look for clues during investigation of a crime, to nab or zero down on criminals. They do not just look at obvious places but non obvious places, too. For instance an investigator looks at a dustbin while investigating a murder, finds a cigar in the dustbin and draws inferences about the criminal. Testers usually do not look at clues that surround a crash or hang and miss the actual criminal that many a times is caught by the end user. Log files is one such clue that has helped me nab several other criminals.

Police personnel ask the same question in multiple ways to the same person at different situations and look for consistency with the answer. Anything inconsistent helps them to get fishy and are one step closer to catching the criminal. If a test passes that doesn't mean it really is a "pass". The same test might fail when executed in a different time frame, different input, different tester executing it, different PC, different network, different hardware... If you observe carefully policemen are using consistency oracles to find the culprit.

I am thrilled that I am looking and learning from many other professions, too and I am glad that I am a software tester who is gifted to see the beauty of testing. I must thank God for his blessings. Not all testers are gifted but they can become one such when they start learning from all possible situations, people, things, objects, happening...

-- -- -- -- -- -- --

When you set your mission to become a wonderful tester, the nature will take care of your learning and all you need to do it to keep all your senses wide open. Mother Nature is the best teacher and you wont realize that by reading this sentence unless you experience it.

James Bach, today's leading test expert and testing legend, whose work has affected the entire testing community, is a strong example of someone who forced Mother Nature to teach him by becoming a self drop out of school during 8th grade ( or Standard ). His relationship and thought process is a gift that Mother Nature bestowed on me when I cried to Mother Nature seeking help for learning to test better.

So, set your mission and cry aloud, SHE will help you. SHE would test your passion under turbulent situations but once you pass HER test, you will get more tests and will start learning and enjoying the experience.


Reminder: Registration for the 500 rupees half day testing mania, is still open, so book your seats to experience such wonderful stuff. For details look at the left hand links section of this blog or simply link click maadi.

Learning & On demand lectures & Challenging the challengers

India celebrates September 5th as Teacher's day marking the birth anniversary of the great Dr Radhakrishnan and so today I started getting calls from my students wishing me on the occasion.

I replied, "Happy Teacher's day, to you too"
and then a student said, "No, I am not a teacher".
"Well, haven't you taught yourself?"
... after a pause ,"Oh yes!",
"Well then you are a teacher and maybe you didn't realize it"

The list of people who have taught me things is huge. Not many readers of this blog know that they too teach me when they ask questions as comments and come back and clarify their points or correct me when I have been wrong.

James Bach and Michael Bolton are two big names many think as my only two teachers. I think I am a gifted student to have learned testing from these two people and there are many other people, too. While others help me and teach me to become a better tester, James and Michael goes steps beyond and help me teach other testers.

Why is my teacher list huge?

Its because James and Michael taught me an important thing: How to learn from others although they might not be consciously teaching me?

Without that skill, I just would be less confident about my testing because testing is an activity of learning.
So, I help testers how to learn and that makes them smarter than other testers who don't know how to learn.

On demand from a few students who said I should hold a lecture that is inexpensive as compared to my workshop, here is the announcement on this special day.

The coming September 29th (Saturday), I might be holding a 4 hour session, which of course consists of one of the most exciting testing exercise for a mere 500 rupees in Bangalore. I usually spill a lot of secrets of good testing during my talk and hence you might want to get your seat booked.

In case you wish to attend this session of mine, you could send me an e-mail at pradeep.srajan@gmail.com with a subject line "September 29th - Testing Lecture Registration" and I shall send you the details.

You could pass this on to your colleagues and friends, too, to ensure they join you for this session. It would not put me in loss if there are 50 people attending this session and so if you are planning to register, passing it to your colleagues and friends might be a good idea to increase the chances of not putting me in a loss :)

_ Challenging the challengers _

"Take a look at this, "Today it is no longer important to be a good tester, or have the right technical skills to manage the plethora of problems that you encounter in your day-to-day job as the testing professionals. Increasingly, today software testers require people-oriented skills to survive what can often be a lose-lose relationship with developers,managers and clients." Take a look at this link .

What the hell?

Someone is saying it is no longer important to be a good tester! So here is the e-mail that I sent them for which there is no response, so far:



Hi Accenture Testing Challenge creator,

Please have a closer look at what you guys have written : "Managing people in testing projects - Building, supporting and adding value to your team - Today it is no longer important to be a good tester, or have the right technical skills to manage the plethora of problems that you encounter in your day-to-day job as the testing professionals. Increasingly, today software testers require people-oriented skills to survive what can often be a lose-lose relationship with developers,managers and clients."

Are you sure that is what you wanted to mean?

I strongly feel that you guys in the context of creating interest among people should not misguide them with such words. What would a fresh starter in this field think if he reads such a thing that it is no longer important to be a good tester?

• However, is that condition true in all contexts? Who said that? Can you quote the person who said that?
• Communication, is a part of testing skills, I am wondering how someone wasn't aware of that?
  
• Is that the philosophy of testing prevailing in Accenture?

I am expecting things to change and a reply to this e-mail.

-- Pradeep Soundararajan



Neither did they re-phrase nor did they reply to my e-mail.

The thing that irritates me is the comments section in the link where people don't question it and just keep adding comments. I thought of entering their testing challenge contest but now feel I am not sure of their judgment.

"Oh God! Please help the testing community from people who misguide testers".

There are testers who misguide other testers in all companies and hence it doesn't mean I am accusing Accenture for this but the people in Accenture who are misguiding the community with such a statement.

Claimer: I claim that all opinions that I share in this blog is mine and I am independent enough to think and it is none of my employer or client views.

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

A Tester's Personal Bug Diary & Notes

I was wondering if there is a way that I could spill some of my secrets of finding a lot of bugs in anything I test to other testers who read my blog. I think, I finally found a way in which, I also could tell, how some experts with whom I interact are fantastic bug hunters.

It's not a big deal and it is simple enough for you to follow, if you intend to be wonderful bug hunter.

I got this idea after I did testing for a new application that a company developed and claimed that is tested enough gave it to me to check for some bugs that they might have missed.

It was a very important session both for me and for the company. Another interesting thing for me is that the company had sent their developers on some work to my office and I had a chance to make them sit with me while I was testing. Whenever I found a bug, I said a story. Here is one such: "I have not come across a user who would want to hover the mouse all around his monitor to spot that button, which is an important action that he would want to do after entering so much data. Do you know of anyone who would like to do that?" ...

18 important bugs in 32 minutes of testing and I met the mission that I set for myself - Find important problems, quickly. I said to myself "Wow Pradeep" and then added to it, "How could I do it?"

Rapid Testing taught me to observe patterns, carefully and decode information from that can be of great help and yes it did come handy while I observed the pattern of my tests and bugs that I found. I must admit that 95% of the bugs I found in that session are from ideas that I had already developed testing other applications over the past and by registering the pattern in my brain.

And here is an important question I asked to myself: "Pradeep, can you do this wonderful job all time?"

Here is the answer: No! Not all time because it depends on a lot of different factors, out of which some I can control and some I can't.

The pattern and behavior of our own brain is something that I feel is tough to understand. It responds to the queries we put based on the situation in which it is at that phase. If I am upset over something and I put a query to it, it doesn't retrieve immediately or it might have a performance issue at that context but the wonderful brain needs something to rejuvenate.

What can that be?

"Hey Pradeep, you said you found a way to help testers become fantastic bug hunters and now you try answering something else?"

A tester's brain needs questions and ideas and to rejuvenate, motivate, push, think... it needs to look at your own work. No, my idea isn't to carry a video of all testing you do but a database, for sure.

What kind of a database could it be?

Presenting to you, A Tester's Personal Bug Diary & Notes ( right click, save and open )

I pull my ideas to find a lot of bugs from my database that currently resides on my brain. I am excited about the one that I created and I would be using it and someday, I can just filter the results based on the application I test and find many important problems in a few minutes. I am sure my clients would be willing to pay a lot of money as they see cost v/s value.


Off topic: I added a Copyright section to my blog that says: I, Pradeep Soundararajan, own the copyrights of all my writing in this blog. If you want to reproduce a part or any of my posts anywhere on the web provide a link to the blog or a specific post or if you want to reproduce it as a hard copy, please send an e-mail to pradeep.srajan@gmail.com .

Plagiarism (stealing of posts and not owing credits or claiming to be authors) of any of the content or ideas obtained from this blog would be reported to Cyber Crime Department and my tester friends network is wide enough that ones who plagiarize have lesser chance of not landing in jail.

-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

A good tester clears traps. Who are you?

There is no standard definition of a "good tester" to my knowledge but I am sure there are ways to say if I am doing a good testing. I self certify as a "good tester" and I *think* I am respected because my standards are higher and growing!

Years back, I fell into a lot of testing traps and I fall into fewer testing traps today. The traps that I fall in decides how bad my testing is. It certainly takes time to recover from the traps and hence I lose time which otherwise could have spent adding value to the project.

Customers aren't happy to pay for the time we spend to recover from the traps we fell into. There are times where we ourselves set traps (and jump into it) and there are also times where others or situations sets a trap. Whatever is the source of the trap, we fall into it and the biggest and dangerous of all traps is this: To not realize that we have fallen into a trap or to be reluctant of having fallen in a trap.

Here is an exercise that I worked on, which I think, helps in demonstrating the art of clearing traps in testing. I would call it : 100 questions in 20 minutes - The Art of clearing traps in testing [ PDF file : 104 kilobytes ]

Wishing you a good learning experience!

Do you think I had a specification or requirement document when I took up the exercise?

-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

Apology to my dearmost readers

I apologize to all my dear readers who shocked me with their comments when I announced that I wont be writing further in this blog because (some) Indian testers were plagiarizing (claiming themselves as authors and not owing credits to the author [ me] ) my posts and articles.

Each comment that I received played an important role in reconsidering my decision. Kindly excuse me for that. I am ashamed of my behavior and I understand that things are beyond my intuition because this is not my blog anymore but your blog and your blog will always be active as long as I am alive and I shall be alive for a long time because...

James Bach said, "You can't be killed, your destiny is to help testers"

Yours,

-- Pradeep Soundararajan

How does Testing look from the eyes of Tester Tested?

Michael Bolton, gave me a writing exercise a month back ( to rewrite an article that I wrote without changing the meaning but changing the examples ) when I showed him a piece of my work that was published by Mahantesh Ashok Pattan, a fundoo test professional from Microsoft. Mahantesh currently heads a testing excellence team in Microsoft's Hyderabad campus. Mahantesh honored me when he asked if I could write an article for his upcoming software testing website. So here goes my exercise result ...

How does Testing look from the eyes of Tester Tested? Version 2.0

Testing - from my eyes looks different, each day. Everyday, I ensure that I learn something new, observe something more carefully, listen to something more carefully, think deep on a topic that I choose to think, ask questions, read what others write about testing, teach testing to someone, learn a skill from someone, test, self critique my own testing, use Wikipedia/Google, practice the skills that I have developed yesterday, day before yesterday and what you might call as “past” and think about the future.

That doesn’t mean I am a workaholic! How can that be?

3 years back, I went to meet a friend in Jayanagar 4th block, Bangalore. While we we were having a walk the talk session, I noticed 2 child rag pickers running towards a food packet that was lying in a dust bin. A dog was running from the opposite direction, trying to grab the food packet before the 2 rag pickers could get it. The dog lost battle and the 2 rag pickers put their hands into the food packet. I was shocked witnessing this scene (without knowing that a bigger shock was waiting for me)

Today I can say, "The two rag pickers taught me a wonderful lesson that I can apply to testing, to better my testing"

Here is what happened: While the two rag pickers put their hands on the food packet, I shouted, "Drop that, I shall get you good food in a hotel" and their body language suggested to me that they would come with me to the hotel.

I started walking towards a hotel nearby to get them good hot food. Minutes before we reached the hotel, I turned back to see if the 2 guys are following and I noticed that one guy still held the food that he could hold picked from the food packet while the dog had a thankful look at me as the guys had dropped the food packet.

I turned to him and said, "Hey, I told I would get you good food but why aren't you throwing that junk food?"

He replied, "Well, what if the hotel is closed? what if you change your mind? what if you played a prank on us? I still have something to eat as compared to the other guy who doesn't have anything."

Poverty might have made him say that but I was shocked by his thinking capabilities. I am sure he has not had any formal education and everything that he learned is through his experiences in life and is also having the same challenge that we face, "survival of the fittest".

When this incident happened, I must admit that I didn't think of a testing lesson that I could learn from it but an year later when I sat relaxed in my chair after a good heavy meal and I thought about the rag picker incident, something that is related to testing struck me.

We testers lose control of things many times that might have been of great help to do a better testing. For instance, I have worked with testers who waited for the requirement documents to arrive although the product ( in some shape ) was in hand.

The boy who had a little food in his hand still had control of the situation and thought of possible situations in which he might have lost everything ( the food packet and the good hot food that I promised ) had he not done that act. Taking control of the situations ( no matter how hard it is ) is a skill that testers need to conciously practice.

An oracle ( not the database ) is a principle or mechanism in which we identify problems. If you learn and start using oracles consciously, I guess you might be in a position to take control of a situation which demands you to test without specifications or with less or poorly documented specifications.

Case 1: I hand over you my mobile phone and ask you to send an SMS and you see the application crashing for that operation; would you call it a bug/issue? (Although you don’t know what the requirement document for the mobile phone that I possess say)

Case 2: I hand over my mobile phone to you and ask you to open each application and exit it. In all applications you use the Right Soft Key to exit whereas one application demands you to exit using the Left Soft Key. Would you have something to say or ask?

In Case 1 and 2, we are using “oracles” of consistency and heuristics (fallible method of solving a problem) to find or discuss about an issue. Doesn’t that mean having diversified set of oracles, heuristics, and test design techniques can fetch great value for the testing you do?

We have a control over the software, platforms, our thoughts, ideas, questions we can ask, skills that we can put to practice or use when such a demanding situation arises, knowledge that we can bring in, use different heuristics and oracles and try reaching closer to the solution than to stay far away by saying, “Where is the spec, I can’t test without it”. You might want to make a note or mention a risk that a specific document that wasn’t available to you could have helped you go more close to what others might call as “great testing”.

Thats how I learned an important lesson from a rag picker!

Now, you could observe that I was actually supposed to have fun while being with my friend and not think about testing. I did have fun and at the same time I was conscious to see if I have missed an important learning that helped me better my testing. I usually don’t miss the fun nor the learning and hence I hardly get tired.

Here is another story, which I shall connect to the above one, in an interesting way.

A tester reporting to me introduced me to her husband by saying, “This is Pradeep, a passionate tester.” I love to be introduced that way since I am aware that I am one such.

Her husband immediately shot a question: “My friends who are into testing say that bringing testing to their life has caused some serious damages to their relationships, how has it been with you?”

Read my reply to that question, as careful as possible: “Thanks for asking me this question. I am probably one of the most passionate testers and I am sure that those who really know, what testing is, wouldn’t mess up his/her life with it. It appears to me that your friends who claim to know testing, don’t know that because had they known, they wouldn’t have got it into their personal lives”

I have enjoyed some great relationships with people. If you claim to be a good tester, it means testing has taught you not to get testing into relationships although testing happens between relationships and lives in a sub conscious level.

“Testing is questioning a product in order to evaluate it” – James Bach

Now the time for connecting two stories: The first story says, “There is always a thread about testing that I run in my mind while or after having fun or watching TV or chatting with friends” and the second story says, “If you really know what testing means, you wouldn’t bring it into your personal life”.

Connecting both of them I want to mean, I try to look for opportunities to learn from things that are happening around that I can apply for my testing activity for which I am paid and *not* to use testing as an approach to build/spoil relationships or systems that others are wanting to use after my usage. For instance, after withdrawing cash from an ATM, I do not intend to perform some quick tests, because it might stop the system and someone in emergency might have to go looking for another ATM.

You have been seeing testing from my eyes, time for you to see it from your own eyes, and I hope you see it in a better way than mine, teach me something and help me to see something different from your eyes. E-mail me at pradeep.srajan@gmail.com

---

If you have liked this article, you might want to read a different version of the same and here is the link. If you haven't liked this article, maybe you want to read it again :)

Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

The story of a monk who sold bugs!

In January 2006, I wrote an interesting post in my blog that became one of the favorite e-mail forward among testers in India. To my disappointment, when I got the forward e-mail from a couple of people, I could see different names as authors in it and I never got the credit. I bet no one can make the kind of creative grammatical mistakes that I do and its always easy to spot my writing. Also as Michael Bolton pointed out in software-testing list, "Pradeep writes from heart".

Fearing those idiots who did not owe me credits I didn't want to write such stories that could make another interesting forward with a claim that they are the authors. I am no coward and most important of all, I don't want my blog readers miss such stories that I have in mind. So here is a story that I think that has gone weeks of thinking:

The story of a monk who sold bugs written by Pradeep Soundararajan [Idiots and fools can change it to their name if wanting to forward the story]

Once upon a time, not so long ago, a monk set out looking for a job in India that could help him earn enough to feed his family. Monk knocked the door of a few software companies and by God's grace, a company did consider him for an opening in testing that they had.

The monk was new to the software industry and had calculated his monthly salary by dividing the CTC ( or cost to company per annum ) by 12 and felt happy about it but when he received his first pay check, he did come to know that maths in software industry, especially when it comes to salary is different. It was not possible to run his family with the monthly pay check he received and hence had to find a way to earn more.

Looking out for another job means, taking time off the work, which also implies that he earns lesser for that month and might end up not getting an offer. So what is the way to work in the same company and yet earn more?

In conversation with other testers in the company during lunch, the monk heard a couple of testers lament about the development teams not fixing the bugs found by them. One tester said, "I bet a 100 rupees on each of these bugs" and other testers too started making similar statements. The monk who was listening to this got an idea and asked all these testers, "did you say 100 rupees to convince developers to fix a bug?" and then testers replied, "Oh yes!"

The monk went back to the monastry in search of his Guru to seek help to win the bet that was placed on each bug. The Guru had left for a world tour but had left a note to all the monks who came in search of him and the note said, "Your problems will be solved even if I am not here to help you and the one who can help you this time is yourself". After reading this the monk didn't get disappointed but thanked his Guru for leaving such a wonderful note.

The monk boarded a bus to head back to office and at the bus he handed over a 10 rupee note to purchase a ticket. The conductor said, "Sorry, I cant give you the ticket, the low battery condition in this ticket generator will make the ticket get stuck during the print out and its a very painful job to remove the paper out and fix the roll in the position and hence we are losing money and business because of this" and the monk said, "Thank you! I got the answer for a question that was bothering me".

The monk, on reaching office called for a meet with other testers and asked them to bring their bug report print outs. Everyone gave their bunch of reports and the monk started his homework.

He picked a bug that was logged with a low battery operation of an embedded product where the developers had commented "Users are not supposed to use the product in low battery". The monk went to the developer and narrated the incident that happened in bus and also added that, "I guess the government is planning to sue the company that provided that machine. As ours is a huge company where different products are developed, are you sure its not our company thats going to be sued?"

That question to a developer was enough for the monk to make his first 100 rupees. As days passed, the monk narrated a lot of real time stories to developers who had offered reluctance to fixing a lot of bugs assigned to them and the monk made a lot of money. As the stories from the monk became popular among the developers in the company, developers loved listening to monk' stories and the monk had a very high credibility among all teams.

The testers conducted a meet and discussed about the monk who made a lot of money through them and decided to cancel their bets thereafter and some testers said, "Ah! I can say better stories, what big deal? Let me convince the developers hereafter and I am not going to pay that already rich monk anymore"

The monk had not only caused a revolution within himself, he had also created an evolution, the way other testers wanted to work.

The monk decided to go to a new place looking for more and different kind of problems. He made a lot of money solving such problems and eventually became one of the richest tester of the world!

Lessons to learn from the story of a monk who sold bugs:

• Everyone needs something convincing to take up a task, be it fixing a bug or executing scripts.
• Developers need some real time scenarios, facts, customer information and information about customers knowledge, models in which the customer uses a product in a packaged form - story - to get convinced to fix bugs.
• One who constantly thinks of solving a problem, will find the solution anywhere.
• The most reliable person for help, is yourself.
• Testers need to develop and practice a skill of story telling to get better at selling bugs.
• Testing is not an activity of improving quality, its an activity of finding information and it is the product/development teams who fix those issues for improving the quality. In case you still want to think that testing is an activity of improving the quality, you might want to become a best bug seller to continue thinking of it.
• Testing is not necessarily a computer science subject and its life science, social science, ... all science and all non science, too.
• There is a traditional way of making money and as a tester if you take the traditional way, you make less with it.
• Some bugs are born with self explanatory story but some aren't and testers need to build them.
• More your sales figure ( selling bugs, I mean) higher is your credibility and as testers if you don't have credibility, you might not be able to boost your sales figures further.
• Pradeep Soundararajan will keep writing such stories without fearing the people who try putting their name as authors and exposing themselves as idiots, fool.

-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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

Let the context drive and yet you be the chauffer

_ marketing starts _

My next public workshop on testing skills is this weekend ( 28th July 2007 ) and I am getting excited. Many testers who got in touch with me over the past are saying, "I will surely attend the next one" and they said this last time, too. I have been asking a question to myself, "Who would attend this workshop then?"

That's funny and I enjoy asking such questions to myself. In case, you are not the one who says, "next workshop", here are the details!

_ marketing ends _

Some testers have liked my blog so much that they have certain expectations from my blog and when I talk about myself in my blog, they get so irritated and ask me over chat, "I come here to read and learn something about testing that can help me do better testing, I don't want to read about you and what you did and all your marketing stuff".

You don't get to see a live cricket match or a Formula 1 race without you being forced to watch the advertisements in between. Anything that you want to keep watching is a business opportunity to someone and they place advertisements and that's marketing for them. When I write about myself, its important for you as my reader to understand that it's one of the way I look for self inspiration whenever I am down. If you want to read something fabulous in this blog, I hope you allow me to read something that I want to read to get inspired and write a post that appears to be fabulous to you.

OK, this post isn't a debate about the above topic but I am sure, I did a mistake in setting the wrong context for what I want to say under the topic "Let the context drive and yet you be the chauffer"

Believe me, I wanted to set a wrong context and that was intentional. Yesterday night, a tester/cum test manager Rahul Mirakhur, the Apple Macintosh Geek you can bet on, had a status "context matters..." and the idea of this post came alive. So here is a context...

When a police man is informed over radio about an accident that took place and he rushes to the scene and he discovers two cars damaged and appears to be a head to head collision. What would your first question be to the people who are fighting with each other if you were the policeman?

All the policemen I have seen try collecting information about the context and try to make a judgment or take an action based on the context information he has.

What if you were one among the two, fighting against an idiot who rammed his car head to head and you discover that he doesn't posses a license to drive the car, yet the policeman arrests you without asking any questions?

Would you not be terribly disappointed?

If you would be then I think you value context a lot.

Now time for you to answer my question: Why does many testers, leads and manager not think about the context information they need to collect ( more than what they think they have collected ) to take a better decision, especially when they have been going wrong. ( If they don't recognize that they have been going wrong, is a bigger problem, of course)

The policeman who arrested you, followed a best practice that states: A guy in an accident scene who is shouting on top of mouth is the culprit! Are you OK with such best practices?

As rupee is gaining Indian business leaders are planning to make all of us work 9 hours a day for 6 days and no more Saturday off. I thought growing economy means things would be more smooth :) [ Refer to this article ]

Why cant we fight back saying, "Hey we will do our work in a more skilled fashion and that's what would result in cost v/s value to our customers in North America and Europe and it's a win-win situation"

Ha ha! I am sure we can never say that because Best Practices drive us. A person who has worked with company X for a long time and implemented a process or style of doing things is hired by Company Y and he tries the same in Company Y but fails. Why?

There are good practices in Context but there aren't best practices!

Ramit Manohar, one of my favorite thinkers on testing from India reports to Vipul Kocher, the President of Indian Testing Board and the Co-Founder of Pure Testing. If I were to practice humility, it has to be looking at Vipul Kocher.


Ramit, during our meet, started saying about a question he often asks in interviews that he claims to challenge testers. I interrupted him and said, "Ok, let's assume that you are interviewing me and why not I try taking up the challenge?"

So, here is the question he asked me: You are riding a bicycle. A pedal comes out. What would you do?

This isn't a testing question! [ that was how most of the testers whom he interviewed reacted because they didn't think of collecting context information about why someone is asking such a question in an interview supposed to hire a tester and ended the conversation there]

You might want to know how a context driven thinker and a skilled tester: clears traps, solves problems, gains situational awareness, learns new things, asks questions, makes a suggestion, proposes solutions, a lot more ...

Here it goes...


What aspect of my thinking would you want to see by making me answer this question?
Flow of idea, lateral thinking, situational awareness, collecting context information ...

Whom are you referring to when you say, "you"?
It's you Pradeep!

Why would I be riding a bicycle when I have a bike and a car?
You are in a race

What do you mean by a race?
Something like Tour De France

Where am I riding a bicycle?
On the busy streets of Bangalore

What do you mean by a bicycle and bicycle pedal? ( I asked him to look out of the window from the coffee shop and showed him what bicycle means to him and the pedal that I am aware of as one was parked outside)
Yeah! That's similar to the one that I have in mind

What speed am I traveling in and are there brakes that appear to work when applied?
Ha ha! How fast can you travel in busy streets of Bangalore? ( I accept, being in Bangalore, that was a stupid question :P ) The brakes are working fine.

Is someone chasing me?
There are people trying to overtake you to win the race.

Does this mean, I am leading the race?
No

Is there something important I missed asking or might add value to me taking a decision?
Yes, there is a bicycle repair shop nearby!

How important is winning the race to me?
You should say that!

Can I assume that I am not bothered to win the race?
There is a huge prize money for the winner.

I dont want to lose that. However, what is it for a person not finishing the race?
He will be shot!

Wait a minute... Are you interviewing me when I stopped the bicycle after the pedal came out? [ the smartest question, in my opinion]
Ah! No

How far is the finish line from the place where the pedal came off?
Not too far!

Is the pedal made of Gold or has a value bigger than the prize money?
Ha ha! I don't think so.

Let me stop it here (although I think you should meet me sometime and listen to the entire conversation between me and Ramit which might excite you, too)

I shall de-brief what might have happened if context related information was not collected, taking the above exercise.

• I might have been shot, if I had not known that the person finishing last in the race would be shot.
• I might have tried too hard to win the race for the prize money whose value is lesser than the pedal that came out.
• A "bicycle" might be a brand name of a car where there was a nasty pedal fitting that restricted the performance of the car. Had I assumed it to be the bicycle I know, I would have not cleared the trap that Ramit *might* have set.
• Had I not asked an important question, "Is there something that I missed to ask?", I would not have found that there was a bicycle shop nearby that might help me in taking better decisions.
• Had I not discovered the speed at which I am traveling and the brakes not working, I might have taken a different decision, all together.

Ramit was so excited and enthused about the conversation we had that he keeps mentioning about me in all the corporate training he does. I am grateful to him, not because he mentions my name everywhere but for giving me an opportunity to practice my skills.

Every question might lead to an answer or to another question, and every answer or question that raises from a question, would lead to asking a potential question that discovers more information about the context.

Why would you want to go to a doctor who never asks any questions nor collects any context information to a patient and starts operating the moment patient says, "head ache"?

If you want the doctors who treat you to be context driven but you are hesitant to be context driven as a tester, you better try not feeling guilty about it!


-- Pradeep Soundararajan - http://testertested.blogspot.com - +91-98451-76817 - pradeep.srajan@gmail.com

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