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

Graphology, Music, Chess, Cooking, Drawing and becoming a better tester

I am observing that every passionate learning tester have tried doing things that are not testing and try to bring in some learnings to testing from doing them, to test better. For instance, Michael Bolton has tried cooking and theater and has benefited by it in testing, you could read his interview in which he mentions that. Michael Hunter (a.k.a The Braidy Tester) has recently blogged about Drawing and how it has been helping him to test and think about testing. Jonathon Kohl's Exploratory Testing-Music of Investigation is no exception. Bach brothers ( James Bach and Jon Bach) are active in Chess.com and you could read how playing Chess helps to test better by reading Jon Bach's post.

CAST 08 has its theme "Beyond the Boundaries: Interdisciplinary Approaches to Software Testing". Interdisciplinary approaches drawn from diversified branches of learning or practice, such that insights can be drawn upon and synthesized to influence a particular craft.

Anuj Magazine, an experienced tester from India has been working for quite sometime on Graphology and Software Testing.

I wanted aid his research and agreed to share my handwriting because his research is to identify the traits in successful testers. You can read the analysis of my handwriting by clicking on this link. I hope you'd enjoy reading the analysis and might be of help to Anuj if he approaches you.

I am sure there a lot of untold stories of what else other than testing has helped them to test better. I hope a lot of other testers come out with those stories that might benefit the community.

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

Educating customers on testing

Everyone has heard about testing and unfortunately everyone has heard about it from different sources that say different and contradicting things.

• One of the customer I worked for thought - testing is about delivering bug free product - which, in my opinion and many other experts with whom I interact is an impractical idea about testing.
• Another customer I worked for thought - testing is about delivering quality - which, again, is a bad idea.
• Another customer thought - testing is about executing test cases and based on the test case pass/fail ratio decide to release - even if the test cases isn't helping testers catch bugs.
• Another customer thought - testing is a job of repeating tests to compare build quality and take a decision to release a specific build to his/her customer.
• Another customer thought - testing is meeting specification.
• Another customer thought - testing is satisfying the customer.

Working with multiple customers is a huge challenge for test managers or testers like me and you. I have so far been repeating the word "customer" and whom do you think I am referring to?

I am referring to the manager we report to and the manager we report to is also our first customer. When testers quit their job and join another one, they never ask their customer (manager) what he/she thinks about testing. That's why some people feel they were performing good in their previous company or they are able to perform better in their recent organization - reason being - their idea of testing matched with that of their manager's idea.

If our idea of testing doesn't match with that of your customer's ( manager ), you and I seem to face a lot of trouble in meeting our customer's expectation and are unable to satisfy them.

Everyone, including you and me might be thinking that the idea we have towards testing is the right one. I have been realizing and teaching that there isn't THE RIGHT WAY to do something. Rapid Software Testing taught me cost v/s value and I took it very serious and I am practicing it.

All customers, irrespective of what definition they have towards testing look for cost v/s value. I am striving to deliver a fabulous value to my customers and I am facing a challenge since I realize what value means to me is different from what value means to my customer (manager).

That's why I was looking as a bad tester (despite finding a lot of bugs) to some of my managers in the past. They think the value they wanted to get out of me is - to execute thousands of scripts or test cases.

Unfortunately I wanted to add more value to the testing efforts which wasn't liked and was fired for attempting to do that. They weren't wrong - they just cleared a trap that they dug in when they hired me.

I learned - what I think as value might be a threat to someone else's idea of value and I value this learning I had about value.

Once I (and my team) found a lot of bugs, so much that there weren't as many bugs that the test case document had helped the team catch in the past. The questions from our customer started to focus on why we had a bad test case document and *not* "Why can't we do more of what you guys did?"

A definition, customer has towards "value" doesn't appear to change despite showing enough evidence. Its hard to continue working for such a customer but there is another dimension to think - money.

Some of those who attend my Exercises for a testers mind - A Rapid Software Testing Approach workshop say, "Well, this is great. I am excited to do testing this way but I suspect the problem is - I don't think my manager would be interested on any of these things I do"

I have had different replies to the above:

• Stop thinking that your manager would not be interested. That's the first step.
• Convince your manager to take this workshop.
• Educate your manager on this.
• Just do it and make your manager ask, "How are you doing these things?"

Here is a list that I suggest you to use, if you realize facing similar challenges: (I practice the same, too)

• Educating your customer, starts with you.
  
• Stop thinking that your first customer wouldn't be willing to see more value.
• Provide evidence for him/her and ask her to critique the evidence you provide.
• Request for a discussion about - What you think of value v/s What your first customer thinks of value.
  
• If it fails the first time, provide repeated evidence and suddenly do things the way your first customer wants to do - see if your first customer comes back asking why suddenly things appear not so good.
• If you have been successful educating your first customer, then motivate your first customer to educate his/her first customer.

BTW, what do you plan to educate your first customer on?

Here is a list of heuristics about educating your first customers:

• Educate yourself before you educate your first customer.
  
• Testing is questioning a product in order to evaluate it AND testers provide quality related information to stakeholders/management to help them take better informed decisions -- James Bach & Cem Kaner
  
• 100 test cases might not help a tester catch 1000 bugs and if you want more bugs, exploratory testing ( with a mission/charter) is an important approach to be incorporated. Adding another 1000 test cases is not a solution.
• Specification document is just one or the oracle that helps a tester find bugs. End users or your customers never use specification oracle to spot bugs and hence going beyond specification can help in finding more bugs.
• Session Based Test Management is a way where Exploratory Testing can be tracked and managed more efficiently.
• Spending less time on documentation that's going to end up wasteful is a nice way to get more time executing tests to find more bugs.
• "If you are too bothered about repeatability of tests - then it is good to have a document of test ideas and *not* test cases that tends to have more ambiguity."
• "Diversification of approaches and techniques helps testers find more and different bugs that otherwise might be caught by a customer."
• Software testing books are not the *only* books that helps tester find bugs and hence the library should stock a lot of books on thinking, ideas, pattern, philosophy, psychology, humans, communication...
• We didn't appear to find a bug because of one or all of these:
  
• We did not have the skill.
• Someone did not let us know when they put it.
• A stakeholder asked us not to report it although we found it.
• We didn't intend to find that.
• We thought it is OK to not to find that, if it existed.
• We were finding other important bugs thinking opportunity cost.
• We didn't have the right oracle.
  
• { You might want to try a lot more, provided some of the above works for you. Sometimes I am aware that I am going to fall into a trap but that's a way I choose to avoid bigger traps }
  

There might be a trap you may fall into. Some of your first customer's might not deserve/ might be reluctant / be egoistic - to such an education, sense it out smartly and stop educating him/her to get more time to educate yourself. An indication that you fell into a trap is when your first customer fires you.

+ A heuristic is a fallible method of solving a problem
++ An oracle is a principle or mechanism by which we (humans) identify problems.

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

Schools of testing, Test experts, and Blood bath - Why do they exist?

In Test Republic, Jayapradeep Joithis posted a topic and discussion under the name "Shun the experts ... Long live the experts" and I replied to it with my thoughts. In this post, I publish, for the first time about Schools of testing and my ideas. In this post, I publish the same because I love to have it on my blog for some of you to comment or question me or Jayapradeep or share your thoughts about it. This is not my personal attack on Jayapradeep Joithis nor I know what school of thought he belongs to.

I have decided consciously to not conclude on things but keep learning about them - Schools of testing is just one of them. As days are passing the list of not to conclude is growing and the learning about them is growing as well. I am happy.

You could either keep track of the above given link or read the following ( a little edited version of the same ).

Here it goes:

First, before you read further, you must know and note that I am *NOT* a testing expert but I interact a lot with some of them, NOT because I love their association that helps me build my credibility or reputation BUT I enjoy the learning I have from them during every interaction.

Jayapradeep wrote "Software testing has become a Ba##$d science . Put the testing experts in a room and u see them going for each others throats in a jiffy."

Put politicians together in a room, you might notice the same.
Put a husband and wife in a room, you might notice the same
Put sales experts together in a room you might notice the same.
Put marketing experts in a room you might notice the same.
Put cricketing experts in a room you might notice the same.

OR

Watch programs like NDTV "We the people" where topics and experts vary from a lot of things happening in and around world are discussed and you *will* notice the same.

Why do you think it is a common behavior among experts?

That's nature! I am happy that you seem to be questioning the nature and I'd be happy if you are doing that for learning - more about the nature and yourself.

JJ wrote "Experts have all the rights to have differences of opinion(after all "when compromises continue REVOLUTION stops) but i always hope it could be done in a more dignified manner and with humility."

At least in Context Driven Community ( to which I associated myself without anyone influencing me to do that ), I have seen people respect each other a lot and have hot discussions. They appreciate each other and agree to disagree, at times. Sometimes one member doesn't want to agree to the other and I think that's perfectly okay because as you said, they have a right to do so.

I think within every school or community - there might be a lot of fight and betterment of ideas or learning as a resultant - that's good.

In my opinion humility is one of the toughest thing for someone to learn and practice. At least for me, I admit openly that I don't know how to express my humility although I think I have plenty of them. It might happen so that I might never be able to learn to communicate my humility. I DONT want to be humble to those who are spoiling the craft and that's when my inability to express my humility is of great help.

We always fight, you always fight - that's nature. You fought your way among several candidates during an interview to get a job. Fighting is our nature. The mightiest, smartest, timely, blessed, and the luckiest ( if it exists ) wins. All of us win at some and lose at the other. When we lose, others might be winning. Sometimes, we lose and win at the same instant.

JJ wrote, "I am no expert nor have insights into what goes on in their minds but what i have seen is that the same experts who speak about creativity , freedom of expression et.c. behave in the most vile manner when their beliefs are questioned."

If you are not the Prime Minister of India, you might not be pleased when he/she announces a war against a neighboring country. You never know why the person took such a decision or does so during a situation. If you want to know that - the only way I can think of is - for you to become a Prime Minister.

There are some test experts who have dedicated their life to better the craft and the rest to make money as testing is offering a huge opportunity to make money.

Betterment of craft means - disproving and taking off those so called experts who are making money and spoiling the craft.

Not that some experts don't bother about money but they wouldn't bother about money sacrificing the betterment of the craft. Money moves everyone and everything that is under "business" clause.

JJ wrote, "Some have become so confrontationist to any opposing views that their tone changes to a jingoistic one, not remembering at many times that there is a fine line between 'proving your point' and megalomania . There is a literally a a blood bath on every forum,group , blog , conference where these experts interact.

They are just being themselves and you and I need not worry about that as long as they offer insightful ideas helping us become better in the craft ( if we want to become )

JJ wrote, "People who oppose semantics and terminology's saying they make u narrow minded go on to propagate their own definitions and terminology's."

Here is a definition of testing that I heard: Testing is a process of making a product bug free!

Really?

By finding bugs - you are not making the product bug free. It is only when ALL bugs can be found and ALL bugs can be fixed without introducing ANY new bugs you might be getting close to it. It is a foolish statement lurking among many testers.

Here is another definition of testing: Testing is questioning a product in order to evaluate it -- James Bach

That's insightful and helps most of us do better as it seems to be insightful that we need to question and provide information to the management take informed decisions. That's all. Achievable and insightful, isn't it?

It is insightful because testers who have subscribed to this definition have done a lot better testing than the ones with the previous definition and are also open to scrutiny about their work. Tell me a test that you did, which is not a question that you asked to the product or environment you tested!

Terminologies and definitions should help people think and not stop them or spoil their thought process or leads them to infinity or impractical ideas.

JJ wrote, "they try to split the community into schools of thought(read the very interesting article by Bret on schools of testing : http://www.pnsqc.org/files/FourSchoolsofSoftwareTesting.pdf ).

Were you ever forced to join one of them?
As long as it doesn't spoil any of your learning or betterment opportunities, do not worry about them.

JJ wrote, "In this game of one upmanship they manage to confuse the bystanders and force them to align themselves to their school of thought. At many times we see its the commercial interests being propagated camouflaged as knowledge sharing.

You can't be confused about something unless you hear or know it. If you came to know about it, it is BECAUSE you were curious to know that. Your CURIOSITY lead to YOUR confusion and NOT they confused you. You could be clear before you read anything that - I am not going to be biased or worry about anything I read or draw conclusions on it the moment I finish reading an article. I am going to experiment and learn from it.

JJ wrote, "As a bystander and a student of testing this has become repulsive."

A true student of testing looks at anything relevant or irrelevant as a learning opportunity.

JJ wrote, "Shouldn't the EXPERTS(respected and self professed) be trying to confluence their ideas?
Do we need to split up into schools of thought?
Do we need to fight over the semantics?


Did anyone, till date, when you approached them, ask you: What school of testing are you from? or Were you deprived of anything because you belonged to one school and not the other?

JJ wrote, "If we look back into history a classical example might come from the schools of thought of the Indian Philosophy, where the schools( Sankhya, Yoga ,Nyaya , Vaisheshika ,Purva Mimamsa, Vedanta) having divergent views still existed besides each other in harmony. They seen as complementary and supplementary to each other and was not an either or not situation. We had the austerism of Mahavira and crass materialism of charvaka having healthy dialogue with each other and co-existing."

I think there exists nothing called a healthy dialogue but I think there exists and existed people who know to make the conversation healthy and there exists people who understand what other person means by healthy.

What do you mean by co-exist?

We co-exist with aliens ( who might be in Mars ) in the same galaxy. We breathe oxygen and they might be breathing nitrogen. I think I made a correct statement because that's my understanding of "co-exist". You might think I made an incorrect statement because it conflicts with your definition of "co-exist".

The four schools of testing do co-exist and I know of many people who are friends with people of other school of thought.

JJ wrote, "Long live the EXPERTS........."

Yes, Let those people, who are experts (or not) and work for betterment of the craft ( with money as secondary interest ) live long or even if they live short let them contribute as much as possible for the craft.

I have seen Context Driven Testing school or community members spoiling the craft for those who want to make money (sacrificing the betterment of the craft) through the ideas that CDT members think of it as a bad idea and a hinder to the betterment of the craft. I think its good to spoil the craft for such people because I too want to see the craft get better and money is secondary. Secondary means - it exists!

The fight is for the ownership of the craft.

Once again, fight is not a bad thing. We all came to existence fighting against one million sperms!

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

Great testing stories from India (Created by Not Following Any "Best Practices")

I would be presenting my workshop on Rapid Software Testing Excersises + a paper at Asia Pacific Software Testing Conference at Kuala Lumpur, Malaysia between Feb 24 to Feb 29, 2008. I wish to thank Vishal Manghani of Processworks Sdn Bhd for the invite.

So, here goes the abstract for the paper I am presenting at the conference:

Great testing stories from India (Created by Not Following Any "Best Practices")

Authored and Presented by Pradeep Soundararajan, Consulting Tester - Satisfice Inc & Test Manager, TriVium Systems, India

When I was 4 years old, I used to eat sand (not because my mother didn't like me eating sand nor for the reason of poverty but as a child, I think, I liked exploring sand as another food option for me) . It was my mother who helped me know my act of eating sand during child hood and referred to me as 'naughty' during childhood.

I could eat sand without knowing it was called 'sand' and I could be naughty without knowing I was called 'naughty'.

When I started my career as a tester and found the first few bugs, I was told by a senior to do more such "negative testing" to find more such bugs. I asked him, "What is negative testing?" and he replied, "Whatever you did to find these bugs is negative testing".

I could do negative testing without knowing that someone refers to what I am doing as 'negative testing'.

Years later, I blogged that I still didn't understand what negative testing means but ideas of what it could be.

It took me a couple of years to learn that I do many things without knowing how someone calls it and then learned from others how some parts of the community I live in calls it.

All these stories indicate that we might be doing great things without knowing it. What is important to us is doing great things and not necessarily knowing the names but it is good to know the names of the great things we do when we intend to communicate with other people.

Anything that works great for me could make you fail badly. For instance, I can live a 100 years eating curd rice and pickle but you may die falling sick of it OR what medicines that could save me from a headache could kill you because although the common problem we might have is headache, the actual root cause is different .

If you disagree to it, 'best practices' fit you well.

If you agree to it, then I am sure you understand why doctors prescribe different medicines for the same person, the next time he /she gets a headache.

In this presentation, you would hear some of the great stories of Indian software testing that fortunately I was a part of and played a role in helping teams achieve the success. What might surprise you is the fact that those teams who did not follow 'best practices' tasted success that teams who claim to follow 'best practices', dream to achieve.

If you are going to listen to these stories in my presentation, I warn you to be aware that you *cannot* see the same success if you try doing things we did.

Welcome to context driven testing!

I would not be able to reveal anymore details about the presentation unless I am done with it but I welcome arguments, questions or success stories that you might want to share with my readers. I think I should be able to publish the slides for the same, post my presentation.

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