The (bad) state of software testing interviews in India

Letter to myself

Dear Pradeep,

Greetings!

I have been with you all this while and shall continue to be with you. I am enjoying each moment you enjoy as a tester and also each moment that you don't enjoy as a tester. I am sorry for enjoying those moments which you think you haven't been enjoying. I am sure you'd be interested to know why and how I have been enjoying those moments that you haven't been.

First, let me list the thing that you haven't been enjoying:

• Whenever and wherever you write about test automation, a handful of readers tend to think that you reject the idea of test automation and they write harsh e-mails to you.
• Whenever and wherever you write about certification, the certified tester community attacks you over e-mails/phone calls that you and I are spoiling the craft.
• Whenever and wherever you write about programming skill for testers, another handful readers think that you are suggesting testers not to learn programming.
• Whenever and wherever you write about tools, most testers think you are referring to test automation tool.
• Whenever and wherever you write about yourself or your experience, a set of people think you lack humility.
• Whenever and wherever you write about exploratory testing as a skilled activity, a set of people think "no tester would do be able to do that".
• Whenever and wherever you write about ideas to solve a problem than giving a one line answer, a set of people think you don't know how to solve it and is faking what you know.
• Whenever and wherever you are writing about testing being an excellent thinking job, a few people think you are trying to paint a picture that does not exist.
• Whenever and wherever you - do bad testing, fail in testing course like BBST, you feel intimidated by more skilled people than you, you feel bad about not having learned or practiced those things that helps you become a better tester, you fail to give enough respect to expert testers time, etc...
  

In this context, I'd like to remind you of a learning you had from Michael Bolton: There are some things under your control and there are other things that are not under your control. Taking advantage of things under your control, as a tester, is essential to clear traps and it might also lead to gaining more control. To take advantage of things under your control, you first should realize what are the things you control.

I also remember that you had made a note in your Moleskine of Saurav Ganguly's television interview where he was asked: How were you able to make a great comeback to the world cup cricket squad after being axed for poor performance? His answer: I didn't worry about things that are not under my control ( media critique, jokes on bad batting performance, e-mail forwards about my performance, people gossiping about it ) but focussed on things that are under my control ( Practice, skill enhancement, consistent batting record in Ranji trophy)

Similarly, you don't have a control over the thoughts of people thinking whatever they think after reading whatever you have written. You have a control over what you write and you have a control over the way you write it.

Your testing has been influenced by a lot of experts but not all have similar influence. They haven't seen great testing to appreciate the things you are sharing and I doubt if all those who witness it would be influenced by it because it's hard work and high skill demanding.

• Not all testers want to do great testing
  
• Not all testers know they are doing bad testing.
• Not all testers want to know they are doing bad testing.
• Not all testers want to know more about testing.
• Not all testers know what skills to gain and practice.
• Not all testers agree to be context driven.

Here are three questions ( like the Monty Python and the Holy grail bridge of death piece you enjoy )

1.Whom are you serving through your writing?

I am sure your ongoing struggle is in understanding that. Let me help you with what I think about whom you are serving - You are serving those testers who look for better thought process and those who enjoy the better thought process and those who think you have a better thought process.

2. Who asked you to serve them?

I asked you to do that!

3. Why haven't you been enjoying some moments that I have been?

You want all testers to do great testing although you know its not possible. Some people question your idea of "great testing" because they already have an idea of "great testing" and it conflicts with the idea you have. You are able to demonstrate that their idea of "great testing" lacks critical thought as your idea of "great testing".

By the way, your idea of "great testing", is not yours but of those people who have influenced you. You have just subscribe to those ideas and are contributing to it in different forms. I have occasionally witnessed you doing bad testing and I am sure I would see that in future, too. Do not forget that you are a human and your ideas are fallible. I know bad testing and bad thought process irritates you, even if you are the one who is doing it.

I would love to see you doing things that are under your control - learning, reading, writing, bettering your skills, helping those testers who enjoy the thought process that you enjoy, speaking, coaching and mentoring.

Your power to influence testers is limited. Limited to the ones who don't want to limit themselves. So do unlimited things under limited time that you and I will be here in this world.

I will be with you forever, enjoying everything you do from great things to not so great things. Anything you do is great to me.

I will write to you whenever I feel a need for it. This letter is personal, just between you and me.

"Here is a way to test if your mission on earth is complete - if you are alive, it isn't" -- Richard Bach

Yours truly,

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

"The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it." --

Reduce Reuse Recycle

I toured Singapore for about 10 days this month. I don't know why my eyes kept catching signboards that suggested people to Reduce, Reuse and Recycle plastics. I think it was because I am from India.

As a part of my tour, I had been to a Zoo and there, I heard the animal show host explaining the need to reduce, reuse and recycle as it impacts the environment and animals.

I felt great about Singaporeans, for stressing the point in many places. No wonder their country ( most parts ) is so clean and tidy that I felt I am in a foreign land. I thought for a while that people in India don't talk about Reduce, Reuse and Recycle as much as Singaporeans do.

16 days after the tour ended, I realized I was wrong. People in India talk as much as Singaporeans do about reducing, reusing and recycling. Here is how they ask:

How can I reduce testing and thereby decrease the cost of the project and increase my profitability?

If testing is a job of providing quality related information to the stake holders to help them take better informed what could reducing testing mean?

I think the people who talk about reducing testing to decrease costs want to know if there is

• a way (or more than one) to make testers more efficient, skilled and competent.
• a way (or more than one) to get information more faster.
• a way (or more than one) to know if they can save costs by not purchasing unnecessary tools.
• a way (or more than one) to know if they can avoid hiring bad candidates.
• a way (or more than one) to know if they could spend less on managing attrition.
• a way (or more than one) to know if they are not doing things that would not add value.
• a way (or more than one) to know if they are meeting the mission.
• a way (or more than one) to know if they can fall into fewer traps.
• a way (or more than one) to know if they can recover much faster from the traps.
• a way (or more than one) to know if they can be more successful in getting more projects.

and : How can I reuse and recycle my test cases, test scripts and testers for future projects thereby reducing the cost of my future projects to increase my profitability?

I think people who talk about reusing / recycling test cases, scripts and testers for future projects want to know:

• many ways (or at least one) to know if they can cut costs by not needing to train testers on a similar domain, technology or product.
  
• many ways (or at least one) to know if they can cut costs by not having to spend time on writing test cases and test scripts for a new project by modifying existing test cases and test scripts.
• many ways (or at least one) to know if they can cut costs by not having to write code that tests code by modifying existing code.
• many ways (or at least one) to know if they can cut costs by not needing to spend much of a time on learning the new product and finding bugs faster.
• many ways (or at least one) to know if by thinking of reusing and recycling, they are definitely saving costs without sacrificing the value they want to add.

Well, if all those who ask the questions knew how to ask it more elaborate or deeper questions, we'd be living in a different world. Thankfully, we still are in the same world.

How did I reuse, recycle and reduce?

• I don't recommend writing test cases and executing tests with the help of that. Although I am not someone who'd like looking at test cases, there was a context in which I looked in to test case document that someone else had written, to gather ideas for my exploratory testing. That's how I reused a test case. It definitely reduced the cost because I took help of an already existing database of ideas. ( That doesn't mean test cases can be handy for ideas to test. A check list, cheat sheet, mnemonics, heuristics... might do it as well more cost effectively).
  

• In one of the several product development organizations I worked for, I identified that a tester was not performing fair enough. I probed for his history of performance within the organization in past projects and recommended him to be fired ( of course, I had the authority to recommend ) He was being paid a lot for he had over 7 years experience. The management feared firing him could send wrong signals to other team members but I asked, "What more right a signal can people get?". On firing him we had money to afford hiring 4 junior testers for 1/5th of what he was paid and got more than what he was delivering. That's how I reduced the cost of the product.

There might be a lot of ways to solve a problem and there might be a lot more ways to not solve them. Unfortunately the ways to not solve a problem appear like the ways to solve problem. Humans are stuck!

If working on reducing, reusing and recycling test cases aren't working, you might want to reduce your intention of reducing, reusing and recycling /and/ think of reusing those ideas in a different context /or /recycle those ideas at a later date when you think the context has changed to suit it.

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

"The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it." --

Using "testing" || Abusing "testing"

As you have started to read this post, before you continue further, I'd like you to listen to a podcast - The Word Test . If you are skipping the podcast, it's OK but it might be a good idea to not skip.

Also, don't read this post while you are mid way listening to the podcast, it's more bad than not listening to it.

One of my student who works for a leading IT services provider from India, asked a question to testers in the organization he works for - "Is it good to stop testing after a couple of years of experience or after promoted to a lead or a manager?" [ My intention of this post is not to answer this question that my student asked but ... ]

There were responses like:

One need not do hands-on testing all through his/her career. When you test all by yourself, you are adding a value of say 'X' to your project. When you manage say 5 Testers, you are letting your skills, knowledge and experience on Testing percolate to 5 other members and you would be adding a value of 5 times X to your project.

and

Whatever you have said is ok for a resource working in a team which uses tools for testing. For someone who is into manual testing where is the career growth? For those wouldn't management be a blessing to be grabbed with both hands?

and

You cant be a tester for all your life. Same is the case with development. You need to manage things at one point in time. But when and where, you need to decide yourself......

and

more such.

All of these people ( including my student ) and maybe testers who are sitting nearby your cubicles while you read this mean "testing" as test execution. [ You wouldn't be surprised at this, had you listened to the podcast ]

Here is my question to those people: If testing means test execution, under what category does - test planning, test data collection, finding bugs, reporting bugs, triaging bugs, test set up, test bed creation, test documentation, thinking of test techniques, exploring, investigating bugs, reviewing test results, test reporting, modeling, diversifying test approaches, etc... fit in?

Well, when the word testing could mean so many things, why are most of us thinking only about test execution when someone uses the word "testing". This makes me question, how many people who claim to be testers really know little about testing that is enough to communicate with people without such ambiguity?

A lot of testers' only thinking is -- every thing in this field is defined pretty well and no need to think beyond it. A definition, in my opinion, should be viewed as a help for a human to think further on it and not in stopping to think beyond what it states.

In another context, if you ask them what "testing" means, they'd love to share their own impractical definitions like:

"Testing is a process of making a product bug free" OR "Testing is a systematic approach towards delivering a quality product" OR "Testing is about following quality processes to ensure bugs don't leak to customer"
and more such stupid stuff !

That's an evidence that the word "testing" itself is context sensitively used by the whole world out of which most of them might disagree with the context driven testing community about their approach. Funny world!

Ben Simo, in a recent conversation, helped me become conscious of the fact that the word "test" is both a noun and a verb; and that one feeds the other.


If one doesn't know what "testing" means, how will they ever know when they are stopping to do it?

If you think you have benefited by this post, here is a "test" you might want to take:

• What would you say, when you want to communicate that you are doing test execution?
• What would you say, when you want to communicate that you are stopping to execute tests?
• What word would you use instead of "testing" to communicate any specific activity that you do as a part of testing?
• When someone uses the word "testing", what would you want to ask them?
• When someone says "test", would you be curious to know if it is a verb or a noun?
• What would you want to know if someone said, "I want to do testing"?
  
• Would you be interested to pass this learning to someone with whom you have been communicating on "testing"?

If you think you haven't been benefited by this post, here are things you could do:

• Read it once again ;-)
• Listen to the podcast, if you have missed it ;-)
• And then exit. It's just not worth one more glance, for today.
  

As testers we use the word "testing" so many times in our life without ever (knowing) wanting to know if we abused it, too. I have done it, too. There is nothing wrong in abusing the word "testing" as long as you don't know that it means a lot by itself and in different contexts.

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

"The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it." --

Automation replaces humans - The truth about what kind of humans it replaces

I often meet people who claim to be "automation testers" and I love and hate to argue with them about test automation. The more I meet such people, I am getting confident about making a conjecture that more than many people who claim to be doing test automating in India and other APAC country testers I visited, are doing it without knowing it or without wanting to know it.

Here are the things they say:

• Test automation replaces manual testing.
• Test automation is faster than manual testing.
• Test automation is cheaper than manual testing.
• Test automation is more reliable than manual testing.
• Test automation removes the monotonous work of a manual tester.
• Test automation provides confidence that the product works.
  
• Test automation is the future.
• Test automation is better than manual testing as a career option.
• Test automation tools provides Return On Investment.
• Test automation can find a lot more bugs than a manual tester.
• Test automation provides more job opportunities.
• Test automation is a way to go about testing.
• Test automation is about converting manual test cases to automation.

Lets look at some of them based on the conversation I have had with such people saying one or more of the above or the questions I'd like to ask you:

Test automation replaces manual testing and Test automation is the future

There are two planes standing there. One of them was tested by a trillion scripts that flew the plane for 400 hours and the other was tested by those 4 humans, flying 100 hours on it. If you were to board one of them, which one would you board and why?

None of those great human beings who said, "Test automation replaces manual testing" said, "I shall board the plane which was tested by a trillion scripts" and instead said, "I will take the plane that humans tested because I feel safer throughout the flight"

So did test automation replace manual testing even for those automating tests?
Test automation is the future of what?

Test automation is faster than manual testing & Test automation is cheaper than manual testing

Here are some statements I make. You can pick ones that makes most sense to you:

A. My Toshiba laptop runs faster than a McLaren Mercedes Formula1 car.
B. My Toshiba laptop runs faster than my old Acer laptop.
C. My Toshiba laptop runs faster on an XP than on Vista.
D. My Toshiba laptop runs faster than that horse which has a broken leg.
E. When someone needs help and I need to run to them, I use a test automation tool because that's faster.
F. QTP license is cheaper than hiring a 5 year experienced skilled tester.
G. QTP is expensive than Winrunner.
I. QTP is cheaper than a Ferrari engine.
J. Winrunner is cheaper than a business class ticket from Bangalore-Toronto.

Option C and G makes most sense. Why? Why not A , D, E, F, G, I, and J?

"Well, option C and G makes most sense to me because you are comparing the same Toshiba laptop when Vista and XP runs on it AND you are comparing two testing tools in G"

Is test automation [ using a software or a computer ] faster than humans to those who say that?
Is test automation cheaper than those human brains who claim to create it?

Test Automation is more reliable than manual testing

I first heard this eye opener, insightful idea from Michael Bolton , "People write code to find bugs on another code. They write code that is buggy which claims to find bugs on another code" and "Writing test scripts is another development project . Most of them don't realize that they are running two development projects in parallel and hence their main development project suffers."

So is test automation reliable than manual testing to those who write code that test another code?
We humans are fallible and all things we create are likely to be fallible, too. Test automation scripts are not excused by God to feel "All test scripts don't have bugs".

That doesn't mean human testing is more reliable. It means, anything done by humans is fallible. When you depend on a fallible thing that a fallible human created, you might not want to talk about reliability there.

Test automation removes the monotonous work of a manual tester

Why is testing monotonous? The unspoken truth!

Test automation is better than manual testing as a career option

Well, people think by becoming an automation tester they aren't doing manual testing. Here is what I have discovered - There are more people who claim themselves as automation testers in India than those who claim to be manual testers. So, let me know which is not manual testing? Can manual be termed as anything that does involve humans?

Lack of skilled testers at least has helped me grow phenomenal in my career. I am not THE skilled but I claim to be one of them and there might be very few like me and not many in India.

Test automation can find a lot more bugs than a manual tester & Test automation provides confidence that the product works

Yes, test automation is very intelligent. If a script is programmed to catch a bug when a value exceeds 5, it can also notice that the value did not exceed 5 and pass the test but the screen went blue for a while. If after all scripts have run and there aren't any bugs found, the test automation suite will alter its values and run once again to catch bugs. As the scripts run over and over again, the scripts learn the product well and if the management needs to take a decision to ship the product they would come near the script and say,

"Oh magical script, I want to ship this product. If you think it's a bad idea to ship now, speak out else remain silent"and then they listen to the script and decide whether to ship or not.

Yes, we are dumb. We can see a numerical value not exceeding 5 and pass the test case but also we can't spot the screen becoming blue for a while and do not report that as an issue while running a test that we claim to pass.


Test automation is about converting manual test cases to automation

Oh wow! So, I can't write automation scripts without writing cases and executing it at least once by my own? And if I write, many might cry "Foul".

Well, test automation scripts are just another program as the program it tests. Did developers have something they did manually before they wrote the code that you test with your manually converted automation test scripts?

Test automation tools provides Return On Investment.

Ok, so here is the industry standard of returns on a tool: For every $500 invested on a tool, a good ROI is about the tool helping the team find 50 bugs.

So, a good ROI for $9000 tool = ( 9000 / 500 ) * 50 = 900 bugs

If that doesn't make sense to you then what is the Return on Investment for a tool?

Bugs? Customer appreciation? The number of testers who get fired? The cost savings of hiring 10 skilled testers v/s the cost of buying the tool? The value that the tool brings to the testing effort? Tons of documentation produced? The added cost of training? The added cost of support? The added confusion that prevails? The number of fake experienced testers who apply to the job of a toolsmith?

Test automation is better than manual testing as a career option

Test automation, at least in India, is more chaotic than the so called manual testing. Hardly any tester knows why they are automating things. You may join any forum where testers are active discussing tools and automation, you'd see questions that the help file of the tool has answers and you would discover replies to such questions that is sometimes horribly wrong and yet the person who asked the question says, "Thanks" and the chaos continues.

There is more chaos among so called automation testers than so called manual testers because the so called automation testers form a huge community than the so called manual testers. More people with lack of insightful ideas means more chaos.

Want to know some useful information about automation or want ideas to think more about it?

Cem Kaner prefers to call most of the automation activities that most testers do as Computer Assisted Testing and I couldn't find evidence to refute the idea. I think it is a great idea to call it "Computer Assisted Testing" and you would know why it is a great idea if you go through this article by Cem or the PDF version of it.

So, all of us irrespective of calling us manual or automation testers do Computer Assisted Testing.

I know of an article written by James Bach that made many people who claims a lot of things about test automation feel guilty and I am sure if you have reached this place reading this post of mine, you'd be interested at reading James Bach's Test Automation Snake Oil - the paper or the slides .

I also know of a blog post from James - Manual tests cannot be automated and Shrini's post on A Mystery called automated testing.

Here is why we do different things in testing such as writing test code, executing test ideas, investigating, diversify approaches, think of different techniques, use heuristics, use oracles, Explore... - because each of them add different kind of value and each of them helps in finding different kinds of information or helps us ask new questions AND NOT because something is better than the other.

There is lot of thinking, reading and writing, I and you require, to know about test automation or about testing. The lazy ones don't get to learn and continue to spoil our craft because they don't stop writing, just like me. [ It's intentional ]

I know I haven't answered a question that you might have in mind but that's intentional again.

Update: Here is Jonathan Kohl's awesome interview about the same topic. Thanks to Konstantin for pointing it out through a comment.

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

"The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it." --

The Bangalore Roti Curry! Now comes with free* testing lessons

Yesterday, I presented a guest lecture on "Questioning Specification and Requirements as a skilled tester" at Edista Testing's newly launched, really unique career program, which I think, can be titled as "Keep learning software testing and we'll keep supporting you to do that" as they intend to keep track of the progress of one's testing career, knowledge and skills even after the completion of the program or after the placement.

One hour after the guest lecture, I hit the treadmill at a gym nearby my home. I love pace walking over the treadmill. Once I get my rhythm , I start thinking about something that doesn't make me focus on how tired I get or how long I have been on a treadmill. Yesterday's treadmill thoughts were about questioning specification, requirement, process, policies, rules, guidelines, best practices...

The common thing about the above list is, "Someone says it, others follow it". Topic I chose to think on the treadmill was interesting enough to help me burn a lot more. I guess for people like me, thinking about following a requirement/rules/policies/process/best practices without questioning burns more calories than running heavy on a treadmill for 30 minutes.

After the workout, I dropped in at a nearby popular and reputed food joint for dinner at Bannerghatta Road, Bangalore.

I bought a token for 1 plate of Roti and curry ( Indian bread ) Cost: 16 rupees. After I got the token in hand, I realized it would not be sufficient and asked if I could get an extra Roti. I had to pay 10 rupees to buy an extra Roti token.

While eating one of the two Rotis, I realized that the curry isn't sufficient for the next Roti and I asked for more curry, I was asked to pay 10 rupees more for extra curry that is of same quantity provided to me the first time.

So here is the interesting thing:

One plate Roti and curry is: 16 rupees : [ 1 Roti + 1 set Curry ]
If I buy an extra Roti and Extra curry: that's 10 + 10 = 20 rupees
Total: 36 rupees [ 2 * 1 Roti + 2 * 1 set Curry ]

If I buy two plate Roti and curry: 16 * 2 = 32 rupees [ 2 * 1 Roti + 2 * 1 set Curry ]

I went to the hotel supervisor and said, "I have never come across any hotel other than yours which has two different prices for the same quantity and item served if purchased in a different order. Is that intended?" and then explained to him the sequence in which I bought Roti and Curry. You might not believe this: He nor the other staff knew that they had been charging customers different rate for the same quantity they buy an item based on the order in which they buy things.

This certainly surprised their staff and I could witness an argument over the issue among other staff members. There was excitement over the issue and I enjoyed the argument between them.

Supervisor of the hotel then assured me that they would fix this issue after consulting the hotel manager and thanked me with a smile for bringing this up.

I was happy. As a tester, I questioned things and provided them information about their service with evidence. I handled it politely and helped them understand how illogical it would sound to people and how their credibility is at stake if they continue to do so.

If I hadn't questioned at the logic, or their menu, or their process, or their specification, I wouldn't have helped them understand something was seriously wrong - because they seem to be concerned to not do anything wrong as it could affect their reputation. They are into this business for at least 5 years and they hadn't realized what rule they set could conflict with their own menu rates.

When customers say "We want A,B, C, D, E, F", they are less aware that A could conflict with E unless we ( testers ) help them understand and that's our job. If we (great testers) don't question requirement/specification/process/rule/guideline/best practices, and the customer by himself finds B conflicts with D at a later stage, he might think of us as fools and maybe get our butts fired.

"If testers aren't questioning, they aren't testing. If testers aren't testing then they aren't testers anymore".

In the Roti Curry story above, I think there is another lesson hiding. As a customer of the hotel, I realized I wanted more, only when I got some bit of it - which means I didn't know how much I needed to buy till I saw some sample. If someone were to have collected my requirement/need, I would have stated something and changed it because I am not sure what I want.

There are a lot of customers who are not sure what they want and if we ( great testers ) are to follow a document that was prepared so early in the project before the customer could see something, we would never be doing what we should be doing. Testing is *not* satisfying a customer but providing information to help the management or customer take informed decisions. The information we provide could be bugs, assessment of risks, questions we have, answers we found...

Little does the hotel know that testing lessons are for free when people buy Roti and Curry.

Laugh (if you want): Research Doctors at National Health Research Institute are recommending to take a minute of every day, especially for those in software testing, to laugh out loud at those testers who don't question the specification/requirements/test scripts/test cases/process/best practices.

It is found through their research that the health condition and testing has had a significant improvement by doing so. Researchers also encourage laughing at yourself, if you are one among the testers who don't question.

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

"The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it." --

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

How to show product quality? - (Uncensored Version)

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