Reduce Reuse Recycle

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

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

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

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

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

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

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

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

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

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

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

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

How did I reuse, recycle and reduce?

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

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

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

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

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

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

Using "testing" || Abusing "testing"

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

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

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

There were responses like:

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

and

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

and

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

and

more such.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

The most challenging software testing quiz

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

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

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

Good luck!

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

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


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

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

Let the context drive and yet you be the chauffer

_ marketing starts _

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

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

_ marketing ends _

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

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

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

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

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

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

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

Would you not be terribly disappointed?

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

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

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

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

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

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

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

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


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

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

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

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

Here it goes...


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

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

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

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

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

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

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

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

Does this mean, I am leading the race?
No

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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