Heroes of software testing - Do you know about them and their work?

My initial plan was to board the flight to Toronto on July 11th from Mumbai to attend CAST 08 software testing conference. Sangeeta, a tester from Mumbai influenced me to change my plan and organized a lecture in Ness Technologies in Mumbai.

I liked the offer and accepted it, as I knew I would enjoy the experience. It's fun to meet new testers, talk to them and learn new things. I am in constant search for budding testers like Sharath Byregowda , Ajay Balamurugadas , Sathish Kumar Chinappa , Sangeeta, Sandesh , Girija, Bhargavi and Nattu ( who accompanied me to CAST 08 ) and those who are passionate and do things about seeing a better tester community like Mohan Panguluri, COO of Edista Testing ... I never know where I can find similar ones. One of the ways that has been of great help to me, to find such testers and thinkers is, while at lectures and my workshops. I offer whatever help I am capable of doing to expose them to good stuff and I do it when they ask me for it.

Here is an excerpt from the talk:

"We are in India, the land where cricket is considered close to being a religion. It has super heroes like Sachin Tendulkar and Dhoni who have inspired a lot of people in India to play better cricket. They could inspire because a lot of people spent their time watching them play great cricket at tough situations. As Indians, you might have seen a lot of people who enjoy playing cricket the way Sachin and Dhoni play. As testers, have you seen anyone doing testing that has inspired you to test better?"

Response: Silence

and then a question comes up from a corner, "Who did Sir Don Bradman see as an inspiration for he is the best known cricketer of centuries?" and all other testers burst to laughter thinking that I was cornered with that question.

I took a while for the audience to settle down and replied,
"I know who inspired Sir Don Bradman" and then a pause to add, "It was himself."
"How many of you are inspired by your own testing?"

Response: Silence

End of excerpt

Reading good stuff as a bad practice and reading bad stuff as the best practice

The above state is what most Indian testers to my knowledge are stuck in. This state resulted because most of testers don't have the habit of reading as though its a bad practice. Most of those who read, are the ones who search in Google and land up at bad sites ( that includes my blog at times ). Most of those who Google search are the ones who are not interested at better thought process but at ready made best practice answers.

There are good and great stuff from internet. I once searched for expert testers and found James Bach. That google search changed my life and the way I test. There were a lot of junk stuff written to attract such search results that I had to pass through before finding James Bach's website. I was sure that I needed help about thought process from an expert tester and not ready made solutions from time to time.

The road to Toronto

I had to face a lot of trouble to get to Toronto. My Visa was rejected ( at the first attempt ), I didn't have sufficient funds ( as per the VISA officials and my bank statement ) , I was denied permission to board the plane as my ticket was booked via United States and I didn't have a US Visa. The Canadian customs had a discussion that bothered me if they would let me in after I landed at Toronto and then my baggage went missing and finally landed as the last one on the belt. Amidst all this was my hope to meet the heroes in real space who have inspired me and to meet those whom I can draw more inspiration from. I believe in God and also believe that God takes a human form to help humans. A great human who lives in 61, Ashburnham in Toronto and the one who lived in my house ( my dad ) helped me and cleared traps so that I reached Toronto and was able to attend CAST 08.


Chasing dreams

Finally I got a chance to meet the heroes who have been inspiring me to test and think better. My super hero James Bach wasn't present at the conference and hence I couldn't meet him. I would be meeting him in November at a conference where we both are invited to speak on testing at a developers conference in Malmo Sweden.

By meeting my heroes, I learned some important things that I could not have learned, had I not met them. I got an insight into the way they live, some ways they think and they communicate. It was several dreams of several years that came true, all in one place - CAST 08.

Not all learning is fun.

If you have understood what I have written in this post so far, then my English writing skill has improved a lot since I wrote my first blog post. It pained a lot to know that I was writing terribly bad English but had I not learned it, I wouldn't have been able to make sense to you in this post.

One of the important things I learned in CAST is the cost of making a few mistakes and the cost of wasting someone's time. I did some mistakes a few months ago but experienced the cost of making those mistakes when I could not stand in front of those people whose time I had wasted. I felt too ashamed of myself but I know I would not feel ashamed for a life time as I am recovering from those mistakes.

Learning is fun as long as you don't learn about yourself and how bad you are in somethings that you want to be really good at. The more I learn that I am bad, I am inspired to work hard enough to get over it. Being a student of James Bach means I keep searching for the answer, "How do I know what I know?" and often I discover what I don't know when I meet and discuss with great minds like the ones I met in CAST 08. I make it a practice to learn what I don't know or what more I'd want to learn on what I want to be good at.


Not all pain is bad

I went all way from Bengaluru ( Bangalore ) to Toronto to know more about myself and how bad I am in things I want to be good at. It hurts but there is no short cut to learning. For those who might disagree that learning could hurt - as testers we provide information about the quality of the product to the management. If we find a lot of bugs, it might hurt the management when they know it especially when it upsets their shipping schedules. It hurts them because they have learned something about their own product. This pain is then converted to measures to not get into a similar situation again. That is what I think some great man said, "No pain, No gain". The things that I learned from my heroes at the conference and other discussions would be reflected in my blog for years to come, so unfortunately keep reading them.


Person dependent software projects and organization

India depended on Sachin Tendulkar for winning a lot of matches. Cricket ( a team sport ) became a person dependent one. Is it a problem for Sachin?

Not really. Actually it demanded him to be at a very good knock and he loved that challenge as it challenged its consistency. It could also be stated that - he faced tough situations and cleared balls beyond boundaries which is why he is admired by millions worldwide.

Similarly, if your organization doesn't want to make their testing a person dependent thing it is because they don't like you to be Sachin Tendulkar . They can't stop from you becoming a Sachin of software testing because it depends on your learning as a tester and not they giving a learning opportunity to you.

You will be interested to read what James Bach wrote about the need for super heroes for software projects long back.

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

It's a "tester" who finds a bug, even with the robust Google Search

The image you might see above is a screen shot of what I saw after hitting the 12th page for the search results of "tester". I am not sure if you can reproduce that because I haven't investigated on it but I did plan to capture it to demonstrate:

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

Be it with the robust systems like Google Search Engine or with weak systems that we might be using, it is always a HUMAN who finds a bug. A lot of testers I know think of "test case" finding a bug.

There is a test case document that consists of 9856985956895869698569956985698459698 test cases and no tester executing it wouldn't find bugs by itself. There is a test case document with 3 documented tests and a tester takes the help of that to find bugs when he executes, observes the result and recognizes a bug.

A test case is an extension of a test idea. What matters to a tester is a test idea and not the test case. Skilled (exploratory testers ( humans ) use tons of ideas ( heuristics and oracles ) to find and recognize bugs. That's why they can find more bugs that matter than those running thousands of test cases over and over again.

Honestly, 99% of testers I have come across didn't say - "I read each test case each time I have to execute it after I have done it once. Also, I religiously follow what is written in the test case".

What happens when they deviate from the documented test case is, they are exploring and running different test. Maybe they don't like to call it that way because their management who pays wouldn't like to know that they are not executing the "test cases".

That's how customers are fooled by management saying "yes, we are running test cases" and yet benefited by the testing community by running more tests.

A test idea can be executed in hundreds of different ways. Check out the deep analysis made by James Bach and Michael Bolton on What Do Scripts Tell Us?


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

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

Reduce Reuse Recycle

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

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

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

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

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

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

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

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

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

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

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

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

How did I reuse, recycle and reduce?

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

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

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

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

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

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

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

Test Case Passed! Who cares?

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





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

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

Why is testing monotonous? The unspoken truth!

My previous post ( Becoming a developer, who is less disturbed by a tester [ in 3 pages ] ) gave me a little surprise when a tester came back saying, "Hey you are helping developers, doesn't that make testers job difficult?"

Another surprise today: 2 testers who were online, pinged me to say that they were doing a monotonous job. When I questioned them I was excited with the work that they had in their hand.

Take a look at one of the conversation:

tester_a: upgrade testing is awfully boring. Any views on this?
pradeep: upgrade testing, what do you mean by that?
tester_a: testing upgrade of a product from older to latest version
pradeep: wow! It's exciting.
tester_a: what would make it exciting?
pradeep: Thinking of what kind of update issues, the product or users might face.
tester_a: there are no issues. it either works or doesn’t. its not scenario specific either and with around 45 platforms to support and 6 methods of upgrade ...its monotonously boring
pradeep: ok, let me give you a list of tests that I might want to test, if I am asked to find important problems quickly.

*What bores a tester always interests the user*.

tester_a: ahan!

pradeep:

1. What if the product while it's getting updated, is hooked off the network?
2. What if an update file is corrupted?
3. What if an update file is infected with virus?
4. What if an update file for a specific platform is fed to another platform?
5. What if your reboot the computers while it's updated?
6. What if the server is reset while a client is updating?
7. What if an application on a client interrupts the update?
8. What if an upgrade fails? What more problems could be hidden with it?
9. What if an auto update and a manual update is attempted in parallel?
10. What if software is attempted to uninstall when an update to it is happening?
11. What if more than one method of upgrade is initiated from the same client with different instances of the application?
12. What if there is an upgrade of the platform happening while the product update occurs?
13. What if the resources required for the upgrade platform are squeezed?
14. What if the update file has wrong information in it?
15. What if the file date is changed to a date than the current version yet it has the latest update?

....

Now, doesn't that sound creative work?

tester_a: doing it on 45 platforms with 7 different ways = 45*7 might not be interesting!!!

a single platform ? Yes sounds "WOW" :)

pradeep: well, let me explain, How I would strategize...

Perform tests on one platform, first. Note the important problems. Look for similar problems on other 2 platforms. If they are serious problems - report and disqualify the build/release/update/whatever?

I would also negotiate with my manager for another resource or two who could help in getting this done effectively by saying, "I fear that any tester to my knowledge might find it tough to do all of that"

If you have been given time, its better you do it with passion.

*The company never thinks it is doing a monotonous job of paying you salary , every month!*

tester_a: lol that was a good reason :) thanks buddy ! You are great help at time like this :)
pradeep: Here is something that you might want to think: Soldiers are asked to work very hard even when there is no war. If they think it's monotonous and quit the job, we die at enemy's hands. There is a soldier guarding you somewhere, far away, and you better not call anything monotonous.
tester_a: hmmm
pradeep: Isn't that true?
tester_a: it’s a debatable topic
pradeep: ok, I suggest you debate with yourself on that.

_ End of chat excerpt _

Why is testing monotonous? The unspoken truth!

1. It's made so by testers who *might* not be able to think or be creative.
2. It's made so by testers who *might* be lazy to run those tests.
3. It's made so by testers who *might* have not learned something that they could apply to the work that they do, to see a different result.
4. It's made so by testers who *might* lack passion to test.
5. It's made so by testers who *might* want to jump to development and needed a reason that others could accept.
6. It's made so by testers who *might* not want to try any new test other than the script that they have been given.
7. It's made so by testers who *might* want a reason to jump to another job.
8. It's made so by testers who *might* lack motivation to test.
   
9. It's made so by people who *might* be claiming themselves as testers but aren't.
   
10. It's made so by testers who *might* not have skills to find bugs.
11. It's made so by testers who *might* claim to know testing after knowing definitions and terminologies without knowing how to apply or practice them?
    
12. It's made so by testers who are promoted as a test lead and *might* be happy thinking, "hurrah, no more test execution" and go completely wrong with their career in testing for thinking that.
    
13. It's made so by test managers who *might* not want to allocate more resource for a huge task and yet get it done with a few testers sacrificing the quality and value.
14. It's made so by testers who *might* want to do exploratory testing but are stuck in scripted approach.
15. It's made so by testers who *might* be doing tasks with same mistakes.
16. It's made so by testers who seek guidance from a person who claims to be a tester and who doesn't know much about it and yet offers great advice to his junior to learn tools like QTP, Winrunner, Load Runner, Silk... to get out of monotonous work. ( Actually, running tools for a life time and being a toolsmith and yet claiming to be a tester, is monotonous)
17. It's not testing that is monotonous, it's testers thinking that is monotonous.
    
18. It's made by testers who monotonously say "testing is monotonous"!

Those who question, don't experience monotony. Those who question, experience testing.
If you experience monotony, you aren't questioning. If you aren't questioning, you aren't testing.

Simple!

( A couple of days left before the registration *might* close for an exciting workshop on testing skills. Look for the announcement in the left top corner and register before I start saying, "Sorry" )

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

FAQ's to my rescue

"Hi pradeep I want to add 2 years of fake experience in software testing field to get job. I am fearing about getting caught. What would you reccomend"

I have a podcast on fake experience and Indian testers. You might want to listen to the podcast to know the truth about faking experience in software testing or any other field for that matter and here is the link "Fake experience and Indian testers".

Everyone who adds a fake experience fears about being caught or feel guilty throughout their career and some unlucky ones are jailed. If you plan to add a fake experience, all you need to do is to decide whether you want to travel through your life with guilt and fear of being jailed or paddle smoothly as others who work hard do. Those who add a fake experience are those who indirectly admit that they dont have the brains that work and I pity their parents who think their son/daughter has brains that work. I ask one question to all those who plan to add a fake experience - Would you be happy if you come to know your father also did the same? (unless your father is a politician) You are the role model for your children and if this is what you do, don't expect your children to be any better than you!

If you still haven't listened to the audio link, you are missing something important.

"Pradeep, I am from India and want to know if there is a future in software testing. I am confused as some of my friends are saying software testing has no future"

I usually say, "There is a great future for software testing but not sure if there is a future to people who ask questions about its future"

Here is when software testing has no future:

• When all of us decide to live with bugs that causes us not to perform some important tasks.
• When all of us are ready to pay a huge amount to buy a product that has some issues.
• When all of us are not bothered if the ATM delivers a 100 rupee note as compared to 1000 being deducted for the withdrawal.
• When all of us decide to board a plane whose components have not undergone any testing.
• When all of us are happy to see a online banking system take away all our heard earned savings because we hit the "delete" button by mistake.
• When all of us as customers love bugs than the products in which it exists.
• When all of us decide to pay for an anti virus software that doesn't catch any viruses but multiplies them.
• When all of us are happy and ready to settle a bill that a software error generated and making our monthly rental for a mobile phone connection as 4594858 rupees.
• When all of us decide that we don't buy or use software products in India.
• When all of us decide to walk 100 miles a day and stand in a queue that has thousands of people waiting to book a ticket in a kiosk whose system crashed and is not recovering.
• Maybe a zillion more things.

Its time for you to *think* and decide whether you have a future. Your friends do belong to the "all of us" category and you must be asking such questions to them. If you are passionate, you can create new business opportunities in this field even if it doesn't exist in your time. All it needs it critical thinking. If you aren't a good thinker then certainly there is no future for you in any of the field you work in. Time to look for a real good friendship!

"Pradeep i really have a doubt.....i had been in manual testing for the past 1.5 years...still not gone into Automated testing...I think u know the domain in which m in. People r really scaring me that u will never have future in manual testing...I really got pissed out ....If i like to move into automated testing....whats the stepping stone for it."

Hmm! What do you mean by "still not gone into automated testing"? There is no thumb rule that a tester is mandated to follow to shape his career. It's never like this:
First year of career - Manual testing
Next 3 years - Automation Tester - QTP
Next 3 years - Lead
Next 4 years - Manager
Next 2 years - Senior Manager
Next 2 years - Assistant Vice President

I infer that many people to my knowledge in North America do what they enjoy doing and many people to my knowledge in India do what others feel they would enjoy. I enjoy blogging and hence many testers do read, appreciate, learn and come back. I am not sure people would have enjoyed reading my blog had I wrote something with an assumption that if I didn't write about QTP, some testers might not come back or enjoy reading it, I would have been exposed as a fool.

If you enjoy what you do, you are set to be happy despite the failure you might face. If you do what you don't enjoy doing, you might be unhappy despite the success that you think has come to you.

"...recently i did software testing course from Infics Solutions.now i am trying to get job in the same field.i am attaching my resume with this mail. u plz go thru it...n plz suggest me, whether i can get job in testing field with the the technical skills n the background i have ????? coz in few companies...only B.E. candidates r preferred."

First, if you want to write to someone and expect them to respond to your e-mail, I recommend you to not use a chat style of writing. They might not take you serious and maybe you are repeating this because none of them pointed it out to you.

By going through your resume, I might not be able to say whether you can get a job in software testing but I might be able to say if I have discussions with you on testing if I am looking to hire someone. Your resume or profile is a set of claims that you make about your technical skills and knowledge. By going through the claims your technical skills or the knowledge you have in testing, cannot be quantified, in my opinion.

Also, you have undergone training from a training center that claims to teach testing and yet it appears to me that you aren't confident or skeptic about your chances of getting job in this field. Perhaps, you must help your juniors realize that such a kind of a training hardly helps you develop confidence or build your passion nor it helps you to get a job in software testing.

A good test team needs to be diversified with skills, background of a tester, knowledge... If a company is insisting on having only BE degree holders as candidates then probably they might re-consider their decision when they realize or discover the need to have candidates from different degree and science backgrounds. It is good to have someone who has worked on banking applications with a banking or finance degree in a testing team instead of all members of the team from computer science background.

" ... my boss asked me about automation testing, he wants to automate his projects, just coz he believes that lots of bugs can be found only by automation. can you help me?".

You want to automate things just because your boss feels automation could find a lot of bugs? Well, I don't know about your context, maybe your boss wanted to mean "We could find those bugs that can't be caught by manual computer assisted testing by automating those tests that can be automated".

If I were in your situation, I would point him out to this article written by James Bach to help him get much clear view on what idea I subscribe to about automation, and help him understand what it could do and what it can't.

I came to know from your e-mail that you do a web application testing and you might want to look into tools like WATIR / SAHI (developed by an Indian in Thought Works, Bangalore) and choose the one that suits you. Some commercially available tools like Winrunner or QTP might be less helpful for your project but many to my knowledge in India don't realize it because many people we find around us aren't testers but toolsmith.

"...Before I joined this company there wasn’t any employee specialized for testing, this job was done by developer itself. And even now some times the developers here underestimate testing sometimes...”.

As testers we shouldn't spend time looking who is respecting our profession but instead look for bugs that could build reputation for us within the organization. I happened to work with developers who were from premier universities like IISc and IIT who wondered if I who had studied from a not so premier university could find bugs in their code. Within a month their impression on me changed and they started calling me "crash specialist" and they started valuing testing as an important activity to better their development skills.

We talked about the crashes stories when we met recently and it was great fun on both sides. Probably, instead of waiting for the software testing craft to gain respect, people like you and me can help the craft get better respect by doing good testing.

"Is it necessary that the testers should have the knowledge of coding to do testing? I am really confused sometimes as I really feel I am in wrong profession. Can you advice?"

The necessity is based on the product and context you are working. Diversity is a very important aspect in software testing and I love to give an analogy of Jurassic park movie where we see raptors doing a coordinated attack for a healthy test team. When raptors need to hunt their prey, each of them takes a role - to corner the prey, to distract the prey, to launch a surprise attack...

Now, a healthy test team might comprise of a technology man, domain man, business behind the product - fellow, script wizard, explorer, bug hungry man, lateral thinker, logic analyzer ( man ), general system thinker, plan man, cooler ( man ), Sherlock Holmes and Watson, the inventor, the discoverer.

It's tough to look for all these qualities in one man and also tough to make such people to get together as a team or maybe there is a scarcity. As testers, we need to have skills of at least 3 of them to start off and as we practice testing, we might want to put more men into us.

For instance, you might already be a Bug Hungry Man but you should start growing yourself to a Bug Hungry Man + Sherlock Holmes + General Systems Thinker ... over a few years of experience.

You are also free to discard one or two of them if you feel you are strong with other men inside you. If your team already has a script wizard, you better develop yourself as other personalities. If you are in a team where there is a need of a script wizard despite all other personalities being present in the team, you develop the skill of scripting.

I feel safe most of the times, as I can always find someone who knows scripting but I did scripting in Perl for a couple of months when there was a need and I volunteered to be the script wizard for a while.

"problem that i am facing is that i don't get time to test as i am always busy preparing the metrics, reports, meetings which gives me goosbumps - i am not testing."

If you run Cost v/s Value in your mind and if you are training yourself to be a situationally aware person, you might not face such a problem. Instead of having a 2 hour meeting on what could be done for a customer who is expecting a report at the end of the day, it is better to do a few tests and find bugs that might help you in deciding what you could do by the end of the day.

Also, if you spend too much time calculating or preparing a metric sheet which otherwise could be spent in finding more important problems and have a report that is crisp and yet conveys the important information you might not run into problems or might clear such traps in testing.

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

Mixing Scripted and Exploratory Testing

Over the past few days, I have been talking and listening to a lot of testers, leads and managers in Bangalore IT organizations through my Mirchi Test Masala talk and it's a great experience.

I solved interesting problems that boosts my confidence of solving testing problems that Indian IT companies face and I have already started to receive great feedback from testers and managers who attended my talk. I usually don't believe on the feedback forms but I do believe when people talk the change happening in their workplace and that is always a true feedback.

One such problem that I solved for an organization is this:

Manager: I usually ask my testers to focus on finding issues that are important to the release and I see that not everyone in my team finds those bugs that I/management/customer is interested to see with that particular release we make.

Tester: Well, we do follow what he says but he is not being convinced about the work we do. We are finding problems but the problems we find are not of the stake holders interest sometimes.

Manager: There was once a design and code change to optimize performance and we did not have the test cases ready and I had to ask them to do it in an exploratory way but I could see that it did not work well for any of us.

Tester: Thanks that our manager communicated that he is interested to listen more about performance related issues on a specific release and we did exploratory testing but we are not sure why we couldn't find bugs.

Pradeep: Ah! Interesting problem!

This is what I did:

1. First I launched an explanation of my understanding of the problem and asked them, if I understood the problem.
2. On getting a go from both sides, I started to question them individually.
3. The questioning skill plays a vital role, in seeking more information, analyzing the problem and get hold of contexts in which they are speaking.
4. I asked the manager and testers a couple of common and uncommon questions and made them to listen to each other.
5. A specific question that I asked, "What is your definition of performance and exploratory testing?" revealed the solution to the problem for everyone in the room.
6. Interestingly, the manager had a different definition of Exploratory testing from each of the tester. The testers too had their own definitions of Exploratory testing and it differed from each other.
7. I insisted the testers to hereafter ask for what the manager meant by a word/terminology when he assigns them to do a specific task.
8. After that I got them off to a discussion based on a topic over which the manger thought his testers fumbled upon and did a bad job. Interestingly, both ends were now convinced that they could find those important problems quickly since they questioned each other.

Now, there is another problem that testers in all organizations I have been so far and I am going to be for my one day testing exercises workshop will ask my help to solve:

How to mix scripted and exploratory testing?

I understand the fact that Indian IT companies do not want try exploratory testing as a full fledged activity for their projects unless they see results for themselves and they still want to try it out to see if it adds value to their testing.

In one of the projects I worked, I mixed scripted and exploratory testing and the results that the organization saw was amazing. Ah! it worked for me but I can't guarantee that it would work for you but I can guarantee you that it's worth a try.

Before you know how to mix scripted testing and exploratory testing, I suggest you to go through Jon Bach's video on Exploratory Testing and RST appendices . Now, if you crave for more you might want to have a look at Elizabeth Hendrickson's Test heuristic cheat sheet and form something like that to suit your project needs. Of course don't forget to run my screen saver which is now installed and used by all testers in an organization and I am happy to hear that it has been helping them.

Now, it's time to know how to mix it without adding too much cost to the organization and yet find those important problems, quickly.

For every scripted test case you execute, run a test that is not documented in your test case suite, which is fast enough to run and yet not add too much of time. You might want to consider using heuristics for getting on the fly ideas to test the product that you have been asked to.

It's left to you and your skills, to decide the ratio of mixture of Scripted test and Exploratory test and also don't get surprised at the results as you keep practicing this and learn to do it much better.

Rakesh VK, a Senior Tester in DELL is well known within his company for being the tester who finds most number of important problems quickly. While delivering my talk at DELL, I had a chance to talk with him over the secret of being the tester who finds problems that matters the most.

He simply had to say this: "I mix scripted and exploratory testing and I always have been a tester who finds most number of important problems and I enjoy remaining in this position. Also, this has led my manager to get convinced that ET adds great value and he now is happy of other team members doing ET"


Wow! So who is the next Indian tester to become one like Rakesh?

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