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

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

Progress Report 2007 of Pradeep Soundararajan

Happy New Year wishes to all my readers.

It is exactly one year since James Bach officially hired me to represent Satisfice Inc in India. James Bach wrote in his post Satisfice India, "A Satisfice tester, (as my brother Jon, at Quardev will tell you from working for me for 18 months) is expected to be quantum cut above normal testers. We achieve that not through wishful thinking, but through study and practice. A Satisfice tester is always ready to be challenged about his work".

So here is my progress report for 2007 that you might want to go through. When I wrote the report, (which took me a long time to compile, think, laugh and cry as I remembered each moment of 2007) I understood why I think I am one of the most passionate software tester without excluding the fact that I am living among other passionate testers. I finally feel eligible of what credit I got one year before, this day.

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

Becoming a developer, who is less disturbed by a tester ( in 3 pages)

Some articles might have made us go crazy about it. For an author, it is a very different experience when the article he is writing makes him go crazy. This article, is one such that excited me and got me more excited when I shrunk first half of the name of article using first letters of the words and leaving the rest to form ...

Pass it on to your developers! [ It's important for them to know this information ]

Pick your copy of BAD WILD TESTER now for FREE!


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

Letter from India

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

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

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


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

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

Developers Developed by Tester Tested

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

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

1. Festivals and realizations:

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

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

Outcome:

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

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

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

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

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

2. Two to tango:

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

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

Outcome:

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

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

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

3. Patterns and structure of crimes:

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

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

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

Outcome:

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

3.b. Our relationship got stronger.

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

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


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

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

Shore, Offshore!

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

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

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

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

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

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

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

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

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

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

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

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

Test Consulting in 2007 by Tester Tested!

Hi Reader,

In 2006 many of you who popped into my blog were able to return with a satisfaction of learning something.

2007 is approaching and what is in store for you from this blog?

Yeah, I have something more exciting and wonderful learnings to share with you.

Pradeep, how are you confident about that?

Yeah, I am positioning myself as an Independent Test Consultant in 2007

How does that benefit Indian Testers or any tester for that matter?

I am a good enough tester and I have helped many testers, coaching them online and through face to face meetings. I have held a peer conference kind of stuff in Bangalore that encouraged testers to meet, interact and learn from each other. As I am on my own now, I got the freedom to coach and learn from you all out there.

So, coaching is your only service?

While coaching is one of them, I love testing assignments and exercises that challenge me as a tester, so if you or your company is interested in making me test your products, analyze it, profile it and add further value to the product, I do it with great zeal.

There are a whole lot of things, I can do for you when it comes to testing.

Can we have your profile to share it with our management to let them know, you are "good enough"?

Yes, sure. Save a copy of this pdf - Pradeep Soundararajan - Profile June 2007 and pass it on to your management.

I am an individual, what services can I get from you?

No worries, I would love to help any tester who wants to better himself as a tester since coaching such testers help me better myself too. I learn from anyone and anything and moreover, I practice the things I learned.

If you are an individual from any place in India, team up with other testers which makes the cost cheaper.

I think I know better than you, what should I do?

Great! Irrespective of who you are, I like to learn from you.

Does this kind of a consulting thing works in India, while it is working in Western countries?

Yes, it works! (provided we try)

How do we get in touch with you?

pradeep.srajan@gmail.com or +91-98451-76817 ( haven't you looked at my profile yet?)


Thanks and Regards,

Pradeep Soundararajan