Rahul Verma on Fuzzing for software testers : Nov 23, 2009

I think I was stupid to have missed mentioning this tutorial from Rahul Verma on Fuzzing for software testers in my previous post. My apologies to all testers from India for overlooking at our own indigenous talent. Rahul, please forgive me.

Fuzzing is a very interesting topic and I dont want to loose out on attending his session in Bangalore.Have you ever corrupted a file? Have you been curious to see what happens to your system when the database is corrupted? What happens to a live / production server if a file is corrupted? Have you ever experienced a file/data corruption at the customer end and the ripples it caused your organization. I know its very important and thankfully Rahul has focused on it much beyond most of us. If I could better my fuzzing skills, I can extend my competitive advantage.

Once I was a part of a test team whose responsibility was to test multimedia streaming on a Pocket PC. Pesticide Paradox kicked in and our test data was no longer helping us to find problems.

Testers & Blocks Consulting - Puzzle 1

At 9 AM on Aug 13th, 2008, Testerlock, Principal Consultant of Testers & Blocks Consulting, walks into the lobby of Seven Inc in Whitefield, Bangalore and asks for Peter, the Head of Testing. Testerlock, was supposed to attend a meeting with Peter and his team of Test Managers. There had been some testing problems in Seven Inc that had been causing concerns to top management. So, it was Peter's boss Nick Fry, who hired Testerlock to figure out what's going wrong.

After all security clearances, Testerlock was welcomed to a conference room by Peter where his team of managers, Sasha, Rubin, Maria, Vibeesh, Ratan and Ankit were waiting for the meeting. The conference room was quite big and could even fit 20 people with an oval table in the center and Featherlite chromium hand rest chairs . Testerlock's name was already written in one of the paper clips marking his seating position near the door. Everyone in the room had heard about Testerlock through his articles and published podcasts and interviews. As Testerlock sat in his seat introducing himself and shaking hand with the team, he smelled the coffee aroma and while putting his laptop bag down on the table, he asked, "Ah! Can I have a Nescafe too?" and that put Peter's team in surprise about Testerlock's ability to identify Nescafe aroma from other available ones.

The meeting started with Peter displaying the agenda planned and discussing each point with a little bit more detail than an e-mail communication that happened a week back. When Peter stopped, Sasha took over.

While these things were happening Peter was getting confused if Testerlock was listening to all that because Testerlock was constantly writing something on his Moleskine. Testerlock had to several times nod to acknowledge what Peter had said. Nodding has been a practiced way in India to acknowledge having heard something from the other.

Sasha, a Test Manager with Seven for about seven years. That's right, 7 years. Sasha had been a star performer at Seven's Texas office and she looked like one and spoke like one, too. Sasha then started explaining her team's challenges of unable to achieve 100% testing and test case being complex, bugs not being fixed and so on....

Testerlock had just one word to say, "Interesting".

From Sasha to Ankit, and from Ankit to Ratan the problems the team faced were...."productivity of testers, tester developer relationship, lack of good process, best practices not working, budget is too low for good testing to be done, test automation not yielding ROI..." and yet again Testerlock had to say one word, "Interesting" and kept writing a lot of notes on Moleskine.

When it moved from Ratan to Vibeesh and Vibeesh was explaining the challenges his team faced, Testerlock interrupted the meeting asking for directions to a rest room. Before he left for the rest room, Testerlock asked the team to continue sharing the problems faced by them.

When he walked into the room again, he had a kind of style in his walk that meant that he knew what the problem was. 

By then it had shifted from Vibeesh to Maria, and then new set of problems being listed.  By then Testerlock had stopped making notes and was sitting and listening to what Maria was saying.

It was about 11:45 AM when Maria completed flushing her list of problems. Peter was excited to ask Testerlock a question and without hesitating much, he asked, "So, Mr Testerlock, what do you think the actual problem is?"

This time, Testerlock stood up and gave a one word answer. It wasn't the word, "Interesting" but the answer to the question Peter asked.

If you were Testerlock, what would your answer be? ( Your answer need not be one word but it could be. If your answer was already listed by other people who commented think about a different answer or expand on the latter. Maybe you might hit a better one )

Traditional Software Testing Process - The cash cow demystified

So, I don't need to tell you that most of the software testing in the world is outsourced. I live in Bangalore and I assume a considerable amount of the world's outsourced testing projects are here. I meet testers from most of these organizations and hear the same process of testing software although called by different names their organization executives named them.

Most testers I meet lament about the process (or sucked within it for survival ) and approach they are forced to follow and try talking to their management about better ideas and better ways to test. Those executives don't seem to listen much nor willing to change.

Wondering why they wouldn't?

They have hit a cash cow.

Mark Crowther and I were discussing about Code Coverage & Requirements Based Testing in Test Republic and some how drove me to write about the way most businessmen are fooling their customers through the process they love to follow.

So, here it goes with editing and expansion. Assuming Mark from UK or maybe even you outsourced a testing project to me:

• I would spend a couple of days analyzing your requirement document and bill you for X hours per person involved in my team.
• I would spend a couple of days writing a test plan document ( but not refer to it ) and bill you for 2X hours per person involved in my team for preparing it.
• I would spend a month or two writing test case document ( and refer only to it ) and bill you for 10X hours per person involved in my team for preparing it.
• I would then again create a traceability matrix ( just to fool you and your boss about our coverage ) and bill you for 5X hours per person involved in my team for preparing it.
• So far, total of 18X hours per person involved in the team is the billing.
• Assuming X is 50 hours and there are about 10 members in my team, that's 18 * 50 * 10 = 9000 hours of billing with no single bug found yet. ( Mark wrote about it, too )
  
• If you are paying $20 an hour per person on an average, you would have actually given me a business of $180,000 without me or my team finding any bug yet.
• So after investing $1,80,000 on me and my team, you would want some benefits of that. So, you wouldn't pull the project out or move it to another vendor because more or less he would do the same and you would end up paying another $180,000
  
• Then comes the test case execution cycles for our documented 10,000 tests out of a possible hundred million tests
  
• For every new bug that you find out of the releases I make, my team would spend documenting the new test case, getting it reviewed and resulting in slower testing for you and more money for me.
• So assuming running 10,000 tests take 2 weeks for a team of 10 members to execute. Also assuming least 50 cycles of testing, you would have paid me about $140,000 for a coverage whose value might be not worth of the money.
• Of course there is additional documentation of missed test cases and other template filling activities that will be billed to you.
• To fool you further, I would instruct my team to use some expensive license based tools ( what else will I do with the money you are pumping in ) to give you a sense of faster testing ( by foolishly comparing it with human speed of testing ) and call it "Automation Testing". It turns out that these tools could have helped me find bugs that are of not a great value to you but hey, we want to see test case pass more than fail.
• Your coverage isn't improving much because we have converted manual tests to automated tests ( although its not the same test ) but to show you the speed of our tools.
  
• So think about adding another $25,000 and giving you an illusion of an ROI of $100,000 while pumping multiples of $100,000 from your bank account to mine.
  
• The CMM, TMM, Six Sigma, ISTQB scams are built around this eco-system to enable more money flow for hardly any value. Who knows there could be a cut for the people who know all this and yet do it.
  

Why wouldn't a businessman be glad about the traditional approaches to test software?

Are you asking about what happens to the users of the product?

• Lets bother about the users of your product later during our maintenance billing phase. Don't you know SDLC ends in Maintenance Phase? If we do everything right in the previous stages then how do we prove we follow SDLC when there is hardly any work in maintenance phase?
  

While you are reading this, you shouldn't be thinking of this happening only in India but in most parts of the world and even within places like United States and Europe. There are smart businessmen everywhere. At one end they pay us but at the other end use us to make more money. We need money and they need us to make that. Don't make smart businessmen exclusive to India and leave your own country out of it.

I hope those who outsource start pushing for services that doesn't fool them. Who would actually listen to this argument is testers turned businessmen and testers turned outsourcing heads and testers turned business leaders.

Whenever I visit a testing services company and see a testimonial of a customer who talks about the great ROI they got and faster testing, I wonder what a heavy price they paid to believe so.

Exploratory Testing ++ , Context Driven Testing ++ , Rapid Software Testing ++ or else YourMoney --

Don't want to be fooled by outsourcing software testing? One of those who could be of help to you among many folks I know, is myself.

Collection of Notes & Experiences: Bangalore Workshop on Software Testing 1

Approved for Publication by all Participants

Theme: Changing the way people test and think about testing
May 2^nd, 2009
Venue Sponsor: Edista Testing Institute & Test Republic


Participants displaying their K - cards
For more pics, click here

Participants ( not in the o: Ajay Balamurugadas, Aishwarya D Shukla, Guruprasad, Manjunath, Rahul Verma, Rahul Mirakhur, Shrini Kulkarni, Manoj Nair, Ravisurya, Santhosh Tuppad, Shikhar Singh, Raghu Sahay, Sharath Byregowda and Pradeep Soundararajan

Bangalore Workshop on Software Testing officially started with the announcement on my blog on April 12, 2009. We had about 15 people rushing in their registration and abstracts for presentation. When you see the list above, you would know who finally made it.

We tried following the LAWST style peer conference and we think we did. I played the role of host and facilitator. I am sure the next time someone else will play the facilitation. I learned facilitation by observing Paul Holland do it in TWST and CAST. He is an amazing tester and facilitator. We used K-cards and that really worked. You would see in photograph, people holding K cards.

We had a check in and introduction (as there were a few faces who did not know each other) at 9:30 AM followed by Ajay kicking off the first presentation.

Ajay’s presentation: Rapid Software Testing

Ajay talked about the change he had after attending my workshop on Exploratory Testing – A Rapid Software Testing Approach and how it helped him log several hundreds of bugs when he started doing a structured exploratory testing. He explained how he struggled with the templates that he had to adhere and how those test cases filled in templates failed to yield coverage and value.

Ajay brought in an interesting thing: “When I started to log more bugs, people were skeptical of how I was doing it. They used to think I was stocking them and releasing it as required”. In this case, Ajay funded himself for the training.

It surprises me that some organizations get their resources trained to help changes to occur to their work and grow skeptical when they get to witness the change.

Before he finished his presentation, he mentioned how the management started seeing Ajay’s work output as a different value than what they expected out of him. What they expected from Ajay was to run as many test cases as possible and what he ended up producing was finding defects and reporting them in their bug tracking system. That is an interesting one – test cases are there, wherever they are, to help testers find bugs and some managers might be misusing it to show progress of testing. I have heard it happens everywhere in the world and not just in India.

During the facilitated discussion that happened after Ajay’s presentation, Shrini mentioned, “The value depends on what stakeholders defines it as”. However, sometimes some stakeholders might need education from a tester to have more meaningful value definition.

Rahul Mirakhur (RM) brought in the idea of a tester wearing different hats and being able to think the value that different stakeholders might want from a tester.

When he interacted with Support teams in an earlier organization, it opened up a completely new world of information source and that, changed the way he did testing thereafter. It also gave a glimpse on how different functions on a project bring in value and in the case of Support teams case, value is more "after" product release.

As the discussion drifted to bugs, Rahul Verma said, “I see bugs as questions we can ask”

Manoj Nair’s presentation on An attempt for better testing

Manoj talked about the opportunity he got in his project where time crunch and amount of testing to be done, enabled his manager to bestow him with a freedom to do free style exploratory testing (without much documentation) for an important feature in his project. The defects and the information he came up by performing free style exploratory testing made the management to postpone the release realizing the danger. He felt happy with his effort, until he was required to explain the details of test coverage across the feature and provide test case document for the tests he conducted for those features. The test case document he prepared were subset of the entire range of tests he performed because he did not have time to document all those tests. He realized the value of tests he did could possibly diminish through that activity. Looking back at it he felt, if he had used Session Based Test Management, he could had done a much better job in providing test ideas document.

During the discussion, I talked about the idea of a Wiki for changes to the product open to all team members and the value it could have for the test team.

Aishwarya, an undergraduate student asked a striking question, “How much information would be an overflow of information?”

The discussion then digressed to – When is the right time to get testers on the project for which all participants had different ideas and experiences. Many organizations have tried bringing in testers early and late and most of them are not yet sure when to bring them in.

I argued that it depends on the kind of a tester an organization is trying to bring in and other factors. Not all testers are the same. I have witnessed organizations that actively ignore testers in requirements review meeting as they have had a bad experience of bringing in a tester. It makes me think that if I lose credibility, it affects other team members in my test group. That is how important it is for each team member to have and build credibility.

Manjunath’s Presentation of Review of Review of Review of Bug Reports

He talked about his experience in one of his previous organization in the context of bug report reviews conducted to help testers log better and credible bug reports. This exercise was undertaken based on the success of improved bug report quality, post a review of each bug reported from the previous project.

Interestingly, in the second project there was another level of review that happened over the review comments of bug reports. The tester, whose bug reports were review had an option to appeal for escalation if he found the review comments did not fit his (her) bug report. It got many testers to defend each of the review comment of the bug reports they logged. Thus spending more time on a single bug report, instead of finding more bugs. That's opportunity cost. That’s like review of review of reviewed bug reports. Yes, we did have a good laugh!

This process was then declared a failure for the second project as its implementation went wrong and 
ceased to exist thereafter, maybe. 

The process can become so worse that it might eat so much time for so little value. On probing, Manjunath revealed that the review process was actually initiated to help testers write better bug reports. All participants were convinced that the way in which the mission was executed might have been poor and what works in one context does not fit another. I am sure we are going to remember Review of Review of Review of Bug Reports experience report.

Doesn’t it help us understand that the best practices do not work for another project within the same organization because the context keeps changing?

During the discussion, we discussed ways of credible bug reporting and shared our experiences of reporting bugs through Video recording of the bug and the value it has had for people who experimented that. It cuts across communication barriers and I am surprised why this practice is not widely used. Oh! 

Someone hasn't talked about it as "best practice" yet? It then digressed to how much English should testers know and then RM talked about practicing English as a daily activity as opposed to a one time upgrade of English skills.

He provided inferences that it’s (relatively) harder to learn language (or command over it) when we get old compared to when we are young. Shrini mentioned that it is not a "rule" by citing his personal experience of how despite being relatively old (compared to most of the audience), he is constantly on the lookout to learn new things.

We got back to reviewing and then discussed on reviewing as a skill and review effectiveness.

Lunch Time folks!

At about 1:15 PM, we walked to a nearby hotel down the street and carried over facilitation-less discussions over lunch table. A heavy lunch

Then when we returned, something helped us get the heat back… Rahul Verma’s presentation on Confessions of a Fallible Tester

This was a very energetic presentation we had for that day and thanks to Rahul Verma, he did it right at the time it was needed ( post lunch )

He made confessions of the mistakes he did right from the start of the career where he thought testing was not his cup of tea. He just did not confess but also explained how he learned from those mistakes and lived better after each big mistake.

One of his confession sounded very cool - “When senior testers in the team said XXXX XXXXXX was the best tool, I believed it” and then he explained how the project suffered because of that tool or the idea of thinking that as THE BEST Tool.

He explained how he cleared that trap and ended up writing a customized plug in to work with XXXX XXXXXX to make it suitable for his testing context.

He then confessed on another mistake of how two blank lines that caused the test environment to fail to enable the product to be tested over it. He or his team members make turned the case by defocusing the customer to something else when the customer observed it. The message was – Test your Test Environment. I think those who do that today are the ones who have realized the value of it. Many testers just setup and start running their test cases without bothering if test environment is what they intended it to be.

The discussion kicked off and we started discussing about tools. The topics varied from Automation Readiness to Vendors bribing managers to sell their tools to Good code versus Measurable Code.

From Rahul Verma to Rahul Mirakhur’s presentation on My career and experiences in testing

He started with a cool question, "When people say WHY will you want to be a software tester, I ask WHY NOT" and I think that was exciting. RM had some interesting observations about IT people in India – “By the time people realize what they are good at they would be in some other domain and would have beefed up living a luxurious life that doesn’t allow them to shift to something they want to do”

He asked another question “Anyone can be trained on software BUT what can they really do?” and discussed that every human is a born explorer and testing is an innate thing and can be developed by proper training.

He then talked about his experience of witnessing developers who moved to testing because they were interested in testing. He then said based on his experience, “Jump into development first if you are serious about becoming a tester”. He shared the experience and value of hiring a person who earlier worked in a support job.

The discussion post this presentation helped in understanding how many different ways are there to get into testing and the value of taking each way. We also talked about the value of learning testing from other fields and that reminded me of CAST2008 conference theme and presentations from there.

RM went back from BWST and started a blog and has promised to keep posting. Another credible blog from an Indian tester on the way - check out.

Sharath Byregowda’s experience of Session Based Test Management

Sharath talked about his experience of experimenting SBTM on the project he worked for and how he influenced other testers, the management and customers with it. He has detailed it in his blog post and I am sure you'd read go there and read it or maybe even learn from it. His team won an award for achieving great results in his organization that has thousands of testers. In addition, Sharath got another award from Michael Bolton.

We had an interesting comment that - By the time an organization implements some new practice as a "best practice" and penetrate every team, the idea is outdated. It reminded me of Ted Neward’s presentation at Oredev08 where he talks about the time difference of programming language birth to becoming an industry usage.

Shrini Kulkarni’s experience of test automation consulting

Shrini talked about his experience of becoming a tester and then about how he grew from being a fresher in software testing to wherever he currently is. He then talked about an interesting experience of Test Automation Readiness Assessment that he was supposed to do for a client in North America and the challenges he had. Shrini talked about his confidence in doing it although his colleagues thought of it as an impossible task. Shrini detailed the value of collaborating with people like Michael Bolton, James Bach, Cem Kaner and others that have helped him evolve to a Test Automation Expert.

 Shrini also talked about his consulting experience and mentioned that almost all test consulting assignments he witnessed, the client was interested in knowing some "universal" or industry standard benchmark related to testing - be it dev to test ratio or % of project cost that could be associated to testing. His experience was that he rarely witnessed anyone challenging those industry standards. In his opinion - That is hindrance for our profession.

Discussions on Test Automation, mindset and skill set followed Shrini’s presentation until the bell rang at 5:30 PM

We had a quick check out and got on to the socializing evening and facilitation-less discussions. We decided on a Food Court in Koramangala and spent about 3 hours there munching food and discussions on Cricket, Movies, Testing, Food, Beer and Wine.

What a fantastic learning to all of us. I must thank Shikhar Singh and Raghu Sahay for coming down from Mumbai and Pune to attend BWST-1. It was fantastic to note that Aishwarya Shukla, an undergraduate student, wanting to do a software testing project as his final year project after attending BWST along with Santhosh Tuppad who completed Practical Software Testing Training at Edista and has been working on several testing assignments as a freelancer. Every participant asked questions that helped other people learn and discover more about themselves and the work they do.

Once again, special thanks to Mohan Panguluri, Pradeep Chennavajhula and Rachna for providing us the space @ Edista Testing. I wish India has more leaders like them who facilitate knowledge sharing and learning in software testing without just being business minded.

Shikhar went back to Mumbai and wrote an e-mail to me regarding Mumbai Workshop on Software Testing that he is planning. Watch out India!

Here is the list of Post It Notes that all participants contributed as an additional reference points to the discussions we had:

• Only testers can talk about Testability
• Book suggestion: Perfect Software and other Illusions about Testing – Jerry Weinberg
• “Every bug is a duplicate of a master bug that the product fails to do something that is important to work for someone” – if that sounds bad - that's still me.
• Philosophy in Golf & Testing – Adam Goucher
• Bug Advocacy – Cem Kaner
• How to investigate Intermittent Problems – James Bach blog post
• “The best tester is the one who gets the most the right bugs fixed” – Cem Kaner in Bug Advocacy
• Do confess when you screw up
• Turning Numbers into Knowledge – A book by Jonathan Koomey
• Lessons Learned in Software Testing – Kaner, Bach, Pettichord
• “Automation could be a dangerous word for a tester” – Rahul Verma
• “If you have failed big, it indicates you rose to a great height” – Rahul Verma
• Value of Checklists – Cem Kaner’s presentation in CAST 08
• Video Record Your Bugs
• The intake I have had from BWST-1, has questioned what I have learned so far. It has helped me to unlearn and learn consistently - Ravisurya
  
• "When I spoke to support teams, it changed the way I tested, forever" - Rahul Mirakhur “
• After I attended Rapid Software Testing Workshop, my testing improved” – Ajay Balamurugadas
• “The value you add as a tester is like NAV of an investment. It changes every day” – Shrini
• General Systems Thinking – A book by Jerry Weinberg

Letter to myself

Dear Pradeep,

Greetings!

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

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

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

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

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

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

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

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

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

1.Whom are you serving through your writing?

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

2. Who asked you to serve them?

I asked you to do that!

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

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

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

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

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

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

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

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

Yours truly,

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

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

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

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

Here are the things they say:

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

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

Test automation replaces manual testing and Test automation is the future

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

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

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

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

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

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

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

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

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

Test Automation is more reliable than manual testing

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

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

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

Test automation removes the monotonous work of a manual tester

Why is testing monotonous? The unspoken truth!

Test automation is better than manual testing as a career option

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

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

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

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

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

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


Test automation is about converting manual test cases to automation

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

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

Test automation tools provides Return On Investment.

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

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

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

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

Test automation is better than manual testing as a career option

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

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

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

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

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

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

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

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

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

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

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

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

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

The negatives of "negative testing"

Before you proceed reading this post, please take a piece of paper or a notepad and write down what you mean by "negative testing".

Are you done with it?

I spent time investigating what many Indian testers say about "negative testing" by browsing online forums, google search and I also sought help from testers who were online in my buddy list. What you read below till you see a "Meep" are views of testers who responded to me over IM when I asked them - What do you mean by "negative testing"? or When someone says "negative testing", what occurs to you? or What do you think about "negative testing"?

"I infer that some of the people are trying hit on negative tests (the probality of user acting the same is very less) o begin with"

"Testing carried out to test expected behaviour from product by providing wrong (negative) inputs "

"A negative test would be the program not delivering an error when it should or delivering an error when it should not. Negative Testing = (Showing error when not supposed to) + (Not showing error when supposed to)"

"there is nothing called as negative testing.. but there is something called negative test case or test idea.."

"Negative testing is that testing which attempts to show that the application does not do anything that it is not supposed to do"

" input which do not lie in valid domain"

"any testing carried out by passing non reccomded values with an aim of breaking down the application is called negative testing"

"if a developer designed a edit box to accept only numerics and length of 10 nos and if it accepts alphabets which we enter if it accepts either than numerics is negative testing"

"negative testing is checking for scenarios which are not smooth path.."

"Testing aimed at showing software does not work. Also known as "test to fail".in simpl ewords"

"negative testing is something you know tht the values wont support but u need to test it.."

"negative testing for me will be done after validating the postive test cases first"

Look this is an interesting one - "as far i am concerned..i belive there is noting called -ve testing."

Meep!

I am happy that Debasis and Venkat Reddy asked about contexts before they came out with their answers.

I found a lot more definitions by individuals in online discussion forums and orkut communities about what people had to say about negative testing and it's a similar experience to what you have read above. If you are interested Google it up and have fun!

Thinking critical, I conjecture that testers to my knowledge are using the term "negative testing" as a guide word heuristic. They are happy of using it because they found bugs with it, be it whatever they did assuming that they were doing "negative testing".

So doing something that could find bugs is more important than what meaning one has for the technique he is using to test ( in the context of this discussion) BUT testing in a skilled way is more important than just doing it. The problem comes when you have to describe what you did to others, especially when they question the techniques you used. A "stress" test to you might be a "load" test to someone - How would you communicate yourself effectively being in a land of confused terms?

After I wrote the above sentence, I leaned back on my chair for a while and thought the following -

"Negative testing" might have different meanings in different different contexts and the following list are my assumptions of the scenarios where I might have done or might do negative testing -

1. If I find a bug but did not report it, which later turned out to be a critical issue, I did negative testing.
2. If I fail to observe a bug that passed away the screen, which could have been caught if I had practiced my observatory skills, I did negative testing.
3. If I do not learn the product or technology during test execution, I did negative testing.
4. If I do not run cost v/s value in mind and end up doing an expensive test away from the mission, I did negative testing.
5. If I failed to ask questions before accepting the mission or jumping to test, I did negative testing.
6. If I blindly follow the specification document, believing it's a bible, I did negative testing.
7. If I am into automation testing just because my friends said "Manual testing has no future" without realizing that automation testing also involves manual activity, I did negative testing.
8. If I manipulate the metrics, without realizing the impact of it on reputation of the company and myself, I did negative testing.
9. If I freeze my test plan and never bother to change it despite the daily dynamics, I did negative testing.
10. If I mess up my relationships with developers, without realizing the fact that developers are great resource of information for testing, I did negative testing.
11. If I stopped learning or practicing testing skills, I did negative testing.
12. If I spend most of the time in orkut and online groups asking questions about how I could solve my day to day problems with subject "Urgent - Need help", I did negative testing.
13. If I list everything that I have in mind about this topic giving less room for you as a tester to think about this, I did negative testing.

Some testers expressed shock when I said to them that I don't know what negative testing actually means. It's very important to say "I don't know", in my opinion when we really don't know something being asked. How long has it been since you said, "I don't know"?

I recently faced a question from someone who claimed to be my friend but isn't happy of my growth in testing field, "Are you a humble person, Pradeep?".. I said, "I don't know" and he replied, "Well, this answer itself says, you are not". I had to laugh at three things - the situation, myself and then my dear friend.

Not knowing a good enough definition that suits your context while applying it, is a negative thing to happen to the project you are working or for people who are tasking you. When you do negative testing with already a negative happening, you might be finding bugs because the resultant is always positive, mathematically. Ah! That's my imagination and I could be wrong.

I am open to more ideas on this but if you put the comments in a negative way, I might have to make the resultant positive ;-)

Testing in my opinion, should not be classified as positive and negative, it isn't electricity but still someone has done the damage by misunderstanding someone else. I don't know what I did with this post!

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

The 2 hour Mirchi Test Masala

Is there one day in a month that you sit free in office?

Yes, in my experience there have been times where there is more than a day free but let's assume you have 2 hours, wanting to listen or watch something exciting and unfortunately videos and audios are blocked.

Ah! I have had this experience, I wanted to learn a lot but restrictions from the IT department did not allow me to watch all those interesting stuff on internet about testing and what people have been saying about testing. Also, in my knowledge there is not someone who is accessible to be called for a 2 hour talk on testing that excites a tester to do a lot better testing.

Satisfice Tester, Pradeep Soundararajan is now available for these 2 hour talks for FREE*!

* - Free means, absolutely Free! (This would work out a great deal for companies in Bangalore)

Am I stupid to do it for Free* (or) I have so much money that even if I charge you for that, it wouldn't make a a difference?

Actually, it makes a difference for me if I charge you but as I understand the importance of making difference, I love to make a difference for you in 2 hours in terms of the knowledge and skills I can share or display.

Well it is this simple. This 2 hour talk on testing does also help me a lot - I meet a lot of testers, interact with them, get and ask questions, learn new things, help testers learn new things, pass on some valuable information for free... who knows the company might come back asking for a consulting from me!

I must agree that this is one of my marketing strategy. My research and interaction with a few experts in Software Testing says, "Indian companies do need skilled testing but unfortunately they haven't realized that they need it" and here is a chance for them to realize through my 2 hour free talk. I am not only helping myself but I am helping companies to realize that they can do a lot better testing.

Michael Hunter from Microsoft mentioned that I am one of the rising and shining star of Indian testing. Being in India, don't you think "do we really have such a wonderful tester in India and why don't we try him out?" ( A wonderful tester doesn't mean I am an expert but I certainly am one, in future)

I am not the only wonderful tester in India, even you could be one but perhaps I have been tried and tested by many testers. In the recent past I have been coaching a tester from Germany who gets so enthusiastic and excited after each interaction we have and he has been recommending me to many others.

I guess I also need to bring Shrinivas Kulkarni to limelight. If you aren't bent on listening to me you might want to listen to a senior test manager of iGate who is behind success of test automation of iGate. He is a giant when it comes to getting success on automation. People are all around, tap their shoulder and they could do wonders for you. ( I don't know Shrini's schedule but pushing him to do this)

Now here is a small wonder I can do, as I have said earlier: I offer all corporate or testing training centre in Bengalooru ( Bangalore ) or any other place in India a FREE* 2 hour Mirchi Test Masala.

For those non-Indian readers of my blog, Mirchi Masala means "spices"!

So, pick your phone and dial +91-98451-76817 and say "Mirchi Test Masala Needed", the IVR ( me ) would ask you "Please mention a date and time" and if the date and time is free in Pradeep's schedule, the IVR ( me ) would say, "Confirmed: 2 hour Mirchi Test Masala would be delivered on [date] and [time] at your office".

Come on test the IVR, I heard it doesn't crash!

-- Pradeep Soundararajan - http://testertested.blogspot.com - pradeep.srajan@gmail.com

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

Update : 19/03/07 : Huawei, Ionidea, DELL, Celstream and a lot of individuals... in just one week. Are you sure you or your company want to miss this?

Update : 27/03/07 : Hasten Technologies and now Mirchi Talk is going to Chennai, too.
It's now or never!

A study on Test Coaching in India

Hi Reader,

As I am exploring the options of coaching testers in organizations through workshops that exercise a testers mind (that includes me too), I had a learning that I value and I am sharing with you here.

I never received any training as a tester in all the companies I have worked for but did train few people as an employee of a company. I have seen e-mails from the HR - Training, announcing coaching on programming languages from external people who have a reputation of handling the class well.

Does this happen to testing too?

Yes, it does but what is being taught is a traditional approach and concepts of testing. Many Indian testers think there is nothing beyond "SDLC, V Model testing, Types of Testing and Testing definitions" to learn in testing.

I wouldn't say the above training is not good enough but instead I would say, "there is more important thing that a tester should be trained on, *acquiring new skills* to test any product". ( provided you would want your testers to do a skilled testing)

We define, a good tester as someone who knows all the definitions and is able to clear a few certification programs.

Certifications arise for a commercial value and I am not sure how much value it holds except that it can fetch you a job if the person who interviews you also holds the same certification. I know a person in India, who has 14 brainbench certifications on fields like Software Testing, Project Management.... and I am not sure what this certificate means. Does it mean you know something about the syllabus or you know most of the things in the course.

When experts like Cem Kaner, James Bach, Jerry Weinberg, Michael Bolton, Mike Kelly, Jon Bach, Mike Kelly, Elizabeth Hendrikson... might say, "there is lots to learn", I am not sure if the certification really matters when you yourself know you are a good enough tester.

In the last one year, the awareness to become a skilled tester is rising amongst testers in India and by the end of 2007, "skilled testing" is the way any Indian tester would want to think about testing.

Who is helping testers to become high skilled?

There are 5 people -

• Tester
• Manager
• HR
• Training and Development department
• Test Coach

I could see testers who have interacted with me or are my blog readers, proposing my workshop to their teams and across organization. The chain reaction came from their managers by proposing the same to the HR and or Training and Development department. Now the HR is going to play an important role in providing the workshop to the testers in their organization.

I am sure all the above 5 people would work hard enough to grow skilled testing within you and me. James Bach once coached testers in Wipro and Mindtree during his visit to India in 2003 and since then many testers in India have been awaiting his next visit. Michael Bolton too presented Rapid Software Testing in India last year and now he is going to speak in the international testing conference, Hyderabad - Dec 8 and 9. Shrinivas Kulkarni has spoken in a lot of conferences worldwide and to me he looks someone has been living with automation for a long time and that is cool to live with what you are passionate about.

Its mercury rising, Catch up with the heat!

I love to share my experiences and learning with you all. Now that I am becoming an independent test consultant, it helps me do this much better and efficient. Help me to help you ;)

Thanks and Regards,

Pradeep Soundararajan

pradeep.srajan@gmail.com or +91-98451-76817

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