The (bad) state of software testing interviews in India

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

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

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

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

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

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

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

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

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

One of the World’s Most Inquisitive Tester is an Indian

No, not me!

James Bach published a post mentioning that his vote for the World's Most Inquisitive Tester is for Shrini Kulkarni and I am proud, he is from India. The moment I read that post from James, I took my mobile phone outside my pocket, dialled Shrini Kulkarni's number and congratulated him for the appreciation he got and for the challenges he gives to testers through his questions. He hadn't gone through the post before I did, so I was the first to congratulate him and I am happy about that.

Shrini and I have had a lot of cold arguments and moments in the past but somehow I have built good respect for him. He challenges testers with a lot of questions and I love being challenged with tough testing questions because that too helps me become a better tester.

Here is a recent example of a post from Shrini which I thought is a good way to practice brainstorming of test ideas and enjoyed working on the exercise. So, for those who don't pay attention to his blog are missing something.

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

Second time, a company in India wants to hire testers in a non traditional way

What is the company looking for?

As a Test Manager of the company, I am looking for 3 testers, each of whom has spent at least 2 to 5 years testing and learning diversified things in testing. I want to challenge the tester in a permanent position in the company I work for, to solve complex software testing problems, whose main focus would be to question testability and supportability of products and write tools to augment testing activity.

Interview

The interview would typically be a telephonic followed by one full day at office premises (probably a weekend) in which you would be given a mission or different missions to achieve by the end of the day. You would face questions based on your testing activity at the end of the day.

I am not listing the skills you need to have but I know whether I should call you for an interview or not through:

1. Write 2-3 pages about your testing experiences so far. If you reveal any confidential information, although you might be too good, I am not taking the risk of calling you for an interview.
2. You may want to attach your CV or anything you think might interest me to call you.
   
3. Fake experiences would be reported to police, so don't risk yourself.
4. Don't mention, even if you have certification in software testing, because it just doesn't help/ better any chances nor worsens. I intend to hire you for your skills of testing and not your certificate that plenty people found it easy to clear.
   

If you are a fresher, Test anything over web and send me your report. I might still be interested to foster you.

e-mail me your reports to testwithpradeep@gmail.com

Here are some highlights of working with me:

1. All testers who report to me have been enjoying freedom, which is very important for testers.
2. All testers who report to me haven't been asked to do documentation that's wasteful or for the purpose of documenting to follow a process.
3. All testers who report to me have got a chance to be questioned on their work quality and some have been rewarded once they practice the changes suggested and also see a value in doing those changes.
4. At least one tester who reports to me started to blog about her testing activity and the thought process that went through to find some bugs ( without revealing the confidential information, of course)
5. All testers who work with me have had freedom to challenge me (without bothering if I am their Manager or not) or my ideas I propose to test without bothering if that would affect their credibility with me provided they are open to learning and unlearning.
   

If all above looks tough to you and don't want to put in that much of hard work to get a challenging testing role, Yahoo, my filter works.

Here are some traditional stuff:

1. Your designation might be a Senior Test Engineer or Test Lead who reports to me (but don't bother too much about that right away).
2. Your pay is decided by the budget allocated for these positions which is in par with industry standards calculated based on some formulas that I am not aware of. Post observing your performance, your pay is not decided by any formula but solely your performance and the company's performance in market.
   
3. You will be required to join ASAP or within 30 days of the date of offer.
4. The work location would be Bangalore.
5. The 10 year old US based medium sized company I work for respects and value testing, and post me coming in, I see more recognition towards testing given by the senior management.
6. There might be some traveling opportunities in Q3 2008 but no guarantee and don't get attracted just because there might be a traveling opportunity.
7. You may be a tester from any domain as long as you don't have a mental block to learn new domains and technologies.
8. Send in your entries before others steal your chance.
   

The good news for those who are excited about this is, I am sure very few people would dare to compete and hence the competition wouldn't be that fierce. So the more excited and curious you are when you read this, the more likely you might be hired.

So, who are those 3 testers among you who would get this unique opportunity that probably other Indian companies might not offer.

It takes courage to challenge and skills to tackle the challenge. I am calling the skilled and courageous to work with me. Get in touch through testwithpradeep@gmail.com

For those of you who want to know what traditionally companies ask for, hit MonsterIndia or Naukri websites and search for tester job openings. Not to my knowledge anyone asks for skills of testing from a tester, instead would focus on tools knowledge or horribly trivialize manual testing and process knowledge.

Hey look, at least some part of Indian testing is changing with more focus towards human skills! Are you left behind?

You might want to know, when was the first time a company in India wanted to hire a tester by non traditional ways... Simple, when the company I work for hired Pradeep Soundararajan ( that's me ) as a Test Manager at his age of 26 and helped him become the youngest Test Manager of India.

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

E go U go I go of U and I

I have no control over your thought process to restrict you to not read the title as Ego You Go and I go of testers.

Here is what I think about my ego:

• I am egoistic but not at contexts and situations where the ego could kill the possibility of me doing a good testing.
• I am not egoistic because I am so curious that I don't care from whom I learn something that can help me do a good testing.

Which of the above two statements could be true in your case, too?

The passion to become good at the craft we are living in makes us better person, too, and the evidence is from my incomplete research on ego and testers.

In my experience, so far, I have had an opportunity to work with testers from various backgrounds (education, culture, native place, language, the way they were brought up ...) , experience ( in terms of number of years , non testing field experience ), skills ( whatever they think their skills are, whatever I think their skills are), knowledge (domain, craft specific ), interests ( curious to explore testing or curious to explore something else), passion (testing or money or both [ certification - if you like it] ) ... and infer that one of the most common thing amidst this diversity is ego.

People (who think they don't have ego) think those who have ego are the ones who are bad professionals. I ( who is sure that I have ego ) think it is not that bad for people to be egoistic as long as they achieve the mission they have in hand without spoiling opportunities to succeed in future missions with the same team.

I think I have not anything different and I am happy to have identified it.

I am going to discuss 3 cases ( the most common and uncommon ones, in my opinion ) that can help me ( or not help you) to understand what I inferred from what I witnessed, experienced, heard and saw.

Case 1: From Lead to Seed

A senior tester (by designation) got promoted to a Test Lead and thought he'd be no longer expected to execute tests. He is moved to a new product based on a requirement of a Test Lead and finds himself in tough situations where people who report to him aren't respecting his views. What he fails to identify is the need to build credibility by executing tests and understanding the product.

The ego of being a test lead and yet not respected by people who report to him ends up in clashes about ideas to proceed with testing. The manager identifies that it would be a good idea for him to learn the product, execute tests for a while, understand the testing complexity and challenges and then play a role of a Test Lead ( as per what he thinks ) ends up in he taking up test execution. During the process of test execution, the ego is still alive and he is hesitant to ask questions that he thinks his team members would laugh at and finally ends up in not knowing the product well and failing to execute tests in a manner that someone thought it as a right way.

On the other side, the team members who report to him do have an ego that built up during the process of knowing that their team lead knows little about what they are doing.

So the Lead and the team members never get a chance to respect each other. Not to forget is a point that there are similar ego issues between the team members.

I guess that leads to bad testing!

Case 2: Buddy testing and then Bloody testing

A company enjoyed having 2 senior testers (senior by designation and lets call them Shyam and Jagan) who were passionate about testing and their work competed against each other's work output and was a healthy competition, of course. Shyam and Jagan worked on the same product but for different customers. Both of them were known to be good at meeting the mission in hand and the important point to note is: both were thick good friends for over 3 years.

Unfortunately, one fine day Shyam's work is applauded by the management. This act of appreciation hit Jagan hard enough to start building up an ego with Shyam. Poor Shyam, not being aware of this ego that Jagan is building cracks jokes ( as both used to ) on Jagan's work and this hits him more hard.

Shyam who cared for his friend Jagan was left disappointed when he did come to know about the multi storied ego that was building. Shyam eventually found it tough to continue working as he too started building his own version of ego. The ego got translated into an unhealthy competition that ended Jagan to look out for a job where he feels safe to work without such unhealthy competition. Shyam and Jagan still thought alike as they used to and both ended up looking for a job without each other's knowledge.

Both quit the company and moved to different ones more or less at the same time without realizing. Here comes the crux of the story: Shyam and Jagan never felt happy with their work thereafter despite working away from each other because what motivated them to succeed in the past was the healthy competition.

I guess that lead to bad testing - for Shyam, Jagan and to the company they earlier worked together.


All it takes is one second...

It takes just one second to feel egoistic and not do something that you too are aware should be done but that one second might result in making you and others around you as bad testers.

It takes one second for those who stole my posts to admit they stole but makes them feel better forever that I appreciated them.

It takes one second to feel egoistic ....
Case 3: From Manager to Damager

Wait a second, let me write the Case 3 a little later because, I got a mail from a team member who thinks he is too smart because he was appreciated for finding a lot of bugs and is a better tester than me. He is challenging my decision. How can he do that when he is reporting to me? I am going to fire him right away and shall update this post later.


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

Some good testers don't blog and so I think the testing community is unfortunate that they have limited opportunities to learn from them. Some bad testers steal others post and so I think the testing community is unfortunate to fear the fact of why some good testers don't blog. Willingness to learn is a skill that a tester *must* possess in my opinion - which also helps in having a lack of ego. I guess that's how good testing begins.

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

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

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

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

Pick your copy of BAD WILD TESTER now for FREE!


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

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

Curiosity (,s)kills (and) bad testers

Jon Bach ( brother of James Bach ) said, "It's easy to teach technology than to make the students curious" addressing students of a reputed university in United States.

I addressed Masters and PhD students who made into India's premier institute - Indian Institute of Technology, Mumbai because they were more curious than others who prepared for the entrance examinations. The people to whom I spoke were also a part of incubatee company Feast Software in IIT, Mumbai. While returning to Bangalore from Mumbai, I had to spend a night in the airport waiting for the early morning flight.

Michael Bolton, had gifted me a Moleskine Note Book during our first meet and in fact Moleskine notes is something that pulled me and Michael together, more close, even before we had met.

I use the Moleskine Notes - to take notes while I test, to use my time wisely in writing something that can help me do a better testing, to capture all learning that nature has bestowed, to note down points, rants, musings, tips and tricks from testers and testing business guru's I meet.

I offered an Indian version of Moleskine to my student Sathish Kumar, who is a top blogger on testing in Cognizant Technology Solutions internal blogs.

The Moleskine notes had a busy time at airport while I kept thinking and writing a lot of stuff. One such topic that I thought, wondered and wrote is:

What has made me curious about things I hear, I see, I touch and things that I want to see, I want to hear and want to touch?

1. In my childhood, my parents couldn't afford to get me things I wanted and it made me curious to know more about those things when I saw others using it or the ad's associated with it flashed on Television.
2. I was forced to feel ashamed of not knowing certain things by my primary and high school teachers. I could have learned it as the information passed me.
3. Some men appeared to be happy of knowing certain things. I wondered what kind of happiness do such men get when they gain the knowledge on something that interested them.
4. Some people ate a food that appeared to be attractive to my tongue and brains, which I could not afford.
5. A friend of mine claimed to enjoy something ( a toy, an experience at a theme park, a game that he played, a place to which he had been) which I could not because I could not afford it or I was not willing to go for it.
6. Every time when I look back at my own actions, behavior, decisions, foolish stuff that I did... I wonder "why did I do that?".
7. I couldn't be in all professions and hence learning from people in other professions interested me.
8. I was a kid 2 decades ago. ( virtue of being curious )
9. Sometimes I didn't have anything to do and became curious about 'what happens next?'.
10. Knowing people, like Sir Thomas Alva Edison, my father - Soundararajan Govinda Rao, James Bach, Jerry Weinberg, Michael Bolton, Sridhar Krishnamurthy, Ravi Joshi, Sudhindra Haldodedri inspired me to think, "how could I become one such?"
11. I was fooled, several times.
12. I was christened "dumbo" in my teenage by my friends and high school teachers.
    
13. My happiness was directly proportional to the things I knew.
14. I enjoyed breaking rules. ( at home, school and at work - when I am testing )
    
15. I always wanted to be the best (but didn't believe in getting 1st rank in school and college as the way to achieve it)
16. I enjoyed failures and started enjoying more of it when people wondered and asked me "what makes you smile when you fail?"
    
17. Since childhood, I was in love with questions.
18. I enjoyed others curiosity.
    
19. My father made me wait for over 20 years to appreciate any work that I did. ( although I could sense that he felt happy every time I shared a little achievement ). I was curious to get it out from him and the only way is to do something great that he volunteers an appreciation. I wasn't aware of what he might consider as a great work.
    
20. My uncle N. Radhakrishnan, with whom I spent most of my childhood, kept inspiring me with the ways he solved problems that appeared in front of him. Today I realize, where I started off to learn "lateral thinking" .
    
21. James Bach and Michael Bolton tested me against their exercises.
    
22. I am curious to know what points I might have missed while listing this for you.

I doubt if you can show me a great tester who isn't curious about things but I can take a bet - "show me a bad tester, I shall help you discover a lack of curiosity in him". [ he might be curious on something else that doesn't help in testing]

Curiosity makes people to ask questions. Those who question, have more chances to become a better tester or be great problems solvers in the professions they chose.

Ben Simo, a senior tester from United States is one among the most curious people I have recently come across. You could see him write, think and comment on different and wide variety of topics in testing.

"If you are curious, you attract other curious people and hence both of your curiosity grows further". Ben and I have been attracted towards each other's work, blogs, ideas and thought process. Aren't you curious to know more about Ben Simo?

Curiosity helps in curing all diseases that stop you in becoming a good tester. Be curious, get cured!

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

Tester Tested interviews Braidy Tester

Braidy Tester has been interviewing great testers for Dr Dobb's Journal. I think I should say, I was just lucky to have been interviewed by a great tester like Michael Hunter.

Michael Hunter blog is widely read in India too. In fact, it is one of my friend who told me that my interview has appeared in Michael's DDJ blog and I blogged about it: Braidy Tester interviews Tester Tested .

You might want to check http://thebraidytester.com to know more about him, his bio, his articles and presentations.

Michael Hunter is an Expert Tester and Test Architect for top secret projects of Microsoft. Lucky Microsoft!

I thought why not I interview the interviewer - [ Hunter hunted :) ] So, here it goes...

PS: What does "Braidy Tester" mean to you?

MH: “The Braidy Tester” is my personal brand. I often braid my beard (as you can see on my MSDN blog [http://blogs.msdn.com/micahel]). When I was preparing to start that blog I spent some time contemplating what to call it. I wanted something snazzier than “One More Microsoft Tester Blogger”. Eventually I decided that weren't that many testers who braid their beards, so I settled on "The Braidy Tester".

PS: How has your experience of interviewing great testers been, so far?

MH:It is a lot of fun! I enjoy hearing other people's views on testing. I especially enjoy hearing about their favorite bugs!

PS: If you chose to answer one question from your own interview, what would that be? and what would be it's answer?

MH: I'll pick "What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?" I think the most important thing for a tester - or a developer - or anyone - to know is that they will never know everything and so there will always be something more for them to learn. The most important thing for them to do is to go learn it! Learn about testing, development, design, art, music, geography, calculus, how people learn, whatever. I find that everything I learn about has something to teach me about testing.

PS: How do you test the code you write? ( after all the great testing experience)

MH: I am a big fan of unit tests and Test Driven Design. I am way more confident in my code when I have TDD'd unit tests backing it up! I also think about testing while I am developing - what tests will be interesting (and will my code survive them), how can I make my code more testable. I look at my code through white box, grey box, and black box glasses. I run through the checklists and mnemonics I've developed and acquired. Then I give my code to other testers and learn what I missed!

PS: There is a lot of confusion over terminologies and definitions in testing, in my opinion. If you feel the same, how do you handle the confusion when you speak or communicate with a tester whose definitions and terminologies appear to be different from yours?

MH: This can definitely block productive conversations. The first - and often the most difficult - step is to realize a conflict in definitions exists. Once you are aware of that you can make the conflict explicit: "It seems to me we don't all mean the same thing when we say 'dogfoodable'." Then you can proceed to form a common definition.

PS: What thoughts run through your mind when you find a bug in a product you bought.

MH: First I say "Hey look! A bug!" And show it off if it's cool enough. Then I wonder how the company missed it. Then I ask "What would have to be true in order for this company to ship this bug?" That last question is the most interesting I think.

PS: What has been the heights of you enjoying testing?

MH: I enjoy finding bugs. Especially the ones which take time and skill and effort to track down. Showing bugs to developers is fun too. My biggest thrills, however, come when I help prevent bugs from occurring in the first place!

PS: There is always something to learn from everyone and everything around for testers. Do you have an experience that you learned something from a kid?

MH: I find watching children interesting because they are so inquisitive. The younger they are the fewer assumptions they seem to make. When I talk about testing I suggest learning to think like a two-year-old: develop the ability youngsters have to come up with an endless stream of questions about everything. Poke at everything in many different ways and you will almost certainly find a case your developer didn't expect!

PS: Tell us about a ( or a set of ) question that you have been asking yourself and how you found answers to them?

MH: When someone else finds a bug in my area I ask why I missed it. When someone finds a bug in my code I ask what I can do to not make that mistake again. A lot of what I am looking at right now is how I interact with other people. Why did I react so angrily to that person? Why am I happy to help this person and not this other one? The more I understand about how and why I interact with people the way I do, the more I can change my interactions to be more effective.

As for finding answers, partly I formulate theories and test them out. What if I deliberately pause two seconds before I respond or react to something? What if I focus on what the other person is saying rather than deciding what I am going to say in response? I find journaling to be helpful as well. Writing things down helps me figure things out, about bugs I am chasing down, about code I am designing or writing, and about myself.

_ end of the interview _

He started this interview with a word, "Fun" and I am not surprised at all. He enjoys testing and thinking about testing so much. His blog is a addictive for passionate testers. After reading, "Making developers cry since 1995", would you ever want to miss this guy's writing?

Thanks a lot Michael Hunter!

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

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

Developers Developed by Tester Tested

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

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

1. Festivals and realizations:

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

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

Outcome:

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

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

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

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

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

2. Two to tango:

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

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

Outcome:

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

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

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

3. Patterns and structure of crimes:

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

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

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

Outcome:

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

3.b. Our relationship got stronger.

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

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


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

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

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