A roadmap for an aspiring tester

I was assigned with a task to prepare a roadmap to learn testing for a batch of new joiners in our team. The roadmap should include what they should learn and why, how they should learn and from where they should learn. I have compiled an outline which I am sharing it in this post. I believe that there are much more to learn for a tester than what I have managed to list here. I welcome suggestions from all of you as comments.

A tester needs to learn:

There are many technologies a tester needs to learn. Some of them (important ones) are:

SQL: A tester has to do a lot of activities related to database. So it is obligatory for any tester to learn the SQL language. This learning includes concept of RDBMS, SQL queries, query optimization and database administration.

Sources: http://www.w3schools.com/sql/default.asp, http://www.informit.com/library/library.aspx?b=STY_Sql_24hours

 

Excel: Excel is a very powerful tool and capable of doing much more thing than you can imagine. It’s a best friend of a tester. Gain mastery over it.

                Sources: http://www.baycongroup.com/el0.htm             

HTML/DOM: For testing web application efficiently and effectively, one has to understand HTML and Document Object Model. Knowledge on CSS is also good.

                Sources: http://www.w3schools.com/html/default.asp

http://www.tizag.com/htmlT

http://www.w3schools.com/css/default.asp

 

XML: XML is a widely used technology and supported by many testing tools to store data. It’s a must for a tester.

                Sources: http://www.w3schools.com/xml/default.asp

 

Scripting languages: There are many scripting languages such as java script, PERL, python, ruby etc. Learning a few of them comes handy while testing. You can build your own tool to carry out few tasks with the help of a scripting language. Java script is of highest priority. Learning PERL or python is a bonus. Choose your own language.

                Sources: http://www.w3schools.com/js/default.asp

                http://www.tizag.com/javascriptT/

                http://www.learn-javascript-tutorial.com/

                http://echoecho.com/javascript.htm

                http://www.perl.com/pub/2000/10/begperl1.html

                http://www.perltutorial.org/

                http://www.tizag.com/perlT/

                http://docs.python.org/tutorial/

                http://www.tutorialspoint.com/python/

The above mentioned sources are not the ONLY sources. Information is strewn across the internet. Explore as much you can.        

Tools that come handy:

There are several open source tools to carry out specific testing related tasks. There are some cool Firefox/Chrome add-ons. Explore in this area and zero on whatever suits your purpose best. Few of the tools/add-ons are:

Bug reporting tools:

Bugzilla: http://www.bugzilla.org/

Mantis: http://www.mantisbt.org/

Trac: http://trac.edgewall.org/

Redmine: http://www.redmine.org/

 

Add-ons:

Firebug: It’s the most popular and a powerful add-on for Firefox. Below is a link to a nicely compiled mind map of add-ons.

http://moolya.com/blog/2011/03/04/addon-mindmap-for-testers-from-moolya/
 

Selection of tools depends on your requirement. Google you purpose and you shall get the list of all related tools.

Blogs: Repositories of failure/success stories

Make a habit of reading few blog posts regularly. There are hundreds of good blog sites and they narrate their success as well as failure stories. Learn from their learning. You can’t afford to make all the mistakes by your own and learn from them. Life is too short for it. Better if you start writing your own.

The link below provides list of top 100 testing blogs:

http://www.jayphilips.com/2009/11/30/100-software-testing-blogs-and-tweeters/
 

Following are links to some really good blogs out of the above 100:

http://www.satisfice.com/

http://testertested.blogspot.com/

http://tuppad.com/blog/

http://curioustester.blogspot.com/

http://help.utest.com/testers

bangalorehackers.com

http://testobsessed.com

testomate.com

testingideas.blogspot.com

vividtester.blogspot.com

testeriq.blogspot.com

Videos:

This is an effective way to demonstrate things. What you can’t express in writing you can show it through videos. It is a plus who hates to read much (though you have to get rid of this habit).

Following are links to few really nice videos:

1. http://testertested.blogspot.com/p/audio-video-podcasts.html contains audio and video related to exploratory testing and basic of software testing.

2. Future of Software testing by James Whittaker - http://blip.tv/utest/james-whittaker-the-future-of-software-testing-utest-webinar-1507610

 

3. Exploratory testing by Jon Bach - http://video.google.com/videoplay?docid=7894844001159492923

 

4. Open lecture by James Bach - www.youtube.com/watch?v=ILkT_HV9DVU  

5. How to think efficiency in software testing by James Bach- http://vimeo.com/10715536  

6. Becoming a software expert by James Bach- http://loadstorm.com/2009/software-testing-experts-james-bach

 

7. Agile testing- http://www.youtube.com/watch?v=bqrOnIECCSg

 

8. Agile Testing Challenges- part 1 and 2 http://www.youtube.com/watch?v=BZ9hY7NNesk http://www.youtube.com/watch?v=exUrdzpdTg4&feature=related

Knowing the programmer

Having a propensity towards programming, I often sit beside my friend who is a web developer when he is on work to learn the basics of web development. I being a tester, he enjoys my involvement on his work for I scrutinize when he develops. He asks me how should a functionality be implemented, how should the GUI look like etc. Though I am not a connoisseur of programming, there are many occasions when looking at his code, I have found out many potential issues and conveyed it to him. On one such occasion, I was sitting beside him and he was writing some java script codes to validate a form. He was writing a java script function which was supposed to be called when a checkbox is ticked or unticked. I noticed a potential issue on this part of the code. To illustrate it, I have designed that part of the form and also written the java script function. There were few more functionalities in his code but I have kept it simple because it suffices my purpose of addressing the issue. And of course his GUI looked different than mine.

Below is the image of that part of the form. 

Look at the image and guess how this is supposed to work. There are two fields; a present address and a permanent address. If these two addresses are same for a user, he doesn’t have to fill the two fields with same data. Instead, he will just tick the checkbox and the content of first field will be copied to the second field and the second field gets disabled. When he unticks the checkbox, the content of the second field gets removed and it gets enabled.  In fact, this functionality was suggested by me and he appreciated. 

Now I shall give you the code. You copy it and paste it in an editor, save it as an html file. Open the html file and try to figure out the issue. Do not view the code for the java script function. Try out different combinations to figure out the issue. I expect everyone to figure it out because this form has very limited possible combinations and if you work out all of them, you can find it out. If you cannot figure out by looking at the application, go view the code and then try.

Below is the code: (Please replace "#" with "<" and "%" with ">" while saving )

#html%
#head%
#title%#/title%
#script type="text/javascript" language="javascript"%

function setAdd() {
var chkStatus = document.forms["myform"]["chk1"].checked;
if (chkStatus==true) {
document.forms["myform"]["txt2"].value = document.forms["myform"]["txt1"].value;
document.forms["myform"]["txt2"].disabled = true;
}else if(document.forms["myform"]["txt2"].value!=""){
document.forms["myform"]["txt2"].disabled = false;
document.forms["myform"]["txt2"].value ="";
}
return true;
}
                   
#/script%
#/head%

#body bgcolor="gray"%
#form name="myform"%
#center%
Present Address:#input type="text" name="txt1" id="pradd" /%#br%
#input type="checkbox" name="chk1" id="addsame" onclick="return setAdd();" /%
#font size="2" color="white"%Click if present and permanent address are same#/font%#br%
Permanent Address:#input type="text" name="txt2" id="peadd"/%#br%
#/center%
#/form%
#/body%
#/html%

For them who still could not figure out the issue, I shall explain what the issue is and how was I able to figure it out by looking at the code. If you look carefully at the “else if” condition of the java script function, it implies that the second field has to contain some value (it is not blank) in order to be enabled when the user unticks the checkbox. I asked him what if it is blank. Then he replied how can it be blank?  If the user has ticked the checkbox, he must have entered some value in the first field. So obviously the second field has that value. Then I asked what if the user has ticked the checkbox without providing any value in the first field? He immediately launched the application, ticked the checkbox without providing any value in the first field. The second field got disabled. When he unticked the checkbox, the field was still disabled because it had no value. In a way to enable it again, he had to provide some value in the first field, tick the checkbox and again untick it.

When I unveiled the issue before my friend, he confessed that in his work, he has made several such types of silly mistakes and no tester has happened to report them. He could then literally recollect on which project and on which part he had made such mistakes. God forbid those issues to be figured out by the users. He candidly revealed before me that he was under an impression that a tester is not necessarily required for a good developer. But now he had understood the importance of a good tester. He learnt a lesson.

What lesson we the testers learned? By knowing the mindset of the developers, how they implement certain functionalities, we can actually uncover many issues of similar types on different areas of a project or even different projects where that developer is involved. To know about their programming habit, we have to build good relations with them. We have to spend some time with them. We can ask questions to them on how they would implement certain functionalities.

Guessing the password

Being an avid reader, every day I make a point to read some blog posts on testing. I am a regular follower of some good blogs written by some revered testers of the world. One of them is Pradeep Soundararajan’s Tester Tested ! On one such occasion of going thru his blog, I came across a post where he has written about how he uses puzzle exercises to teach testing . Having a great propensity towards riddles, the post seemed very interesting to me. With utmost alacrity, I jumped into solving few of them. This article is about my experience of solving such a puzzle, Guess the Password - Version 1 & Version 2. Anyone who is reading this post and has not yet solved these two puzzles, I request them to go solve them first and then come back and read further.

I tried version1 first. Having solved many online riddles earlier, it didn’t take much effort of mine to guess the correct username/password. I navigated to the version 1 page and tried to find out if any clue related to username/password was displayed on the page. Initially I thought this application must be validated at server side.  I thought there must be some clue displayed on the page itself looking at which we have to guess the credentials. After we give the credentials and press Log In button, the data is being sent to the server and there it is validated against correct credentials stored in the database. Not finding any clue on the page, I viewed the page source thinking I might get some clue written there as comment lines. To my amazement, the first comment line I saw read something like “Oh, you think you could crack it from the source code? You thought it would be so simple?” I was disheartened reading this. If there is no clue either on the page or the page source, how would I suppose to guess the credentials? But knowing something about the way Pradeep and Santosh present exercises, I took no time in understanding that this comment line was meant to deceive the solution seeker. I therefore started looking at the code at it took merely 2 minutes to guess the correct credentials. I started from the form. My knowledge on java script helped me here. I saw a java script function “validate” is being called when the Log In button is clicked. I then realized that my earlier view on credentials being validated at server side was wrong. I jumped into the validate function code. And it was pretty much simple. The values of the username and password fields are being retrieved and stored in two variables. There are two more variables which contain the correct username and password. There is a condition which checks the username and password values given by the user against the correct username and password stored in two variables. If it matches, you have cracked the username/password. Mine matched on first try. 

However, version 2 was not a kind of cakewalk for me. Though the way of puzzling is almost similar to that of version 1, it took me one whole day and a mail to Santosh to guess the correct username and password. After I succeeded, I realized that I had already guessed the correct username and password much earlier but wasn’t combining them properly. The first difference between version 1 and version 2 was the interchange of variables that store the actual username and password. This didn’t take much time to figure out. The next was the username seemed to be a “blank space” and the password as “testing”. I tried the combination only to fail. I then suspected the character which looks like a blank space was not actually the same blank space that can be generated by the space keystroke on the keyboard. I was aware of a character like this. But I acted over smart, copied the space like character and pasted it in the username field. This didn’t help either. Then I thought of copying the entire source code to a notepad and save it as a local html file. I did so. I then opened it and gave the combination “blank space” and “testing” and hit Log In. Bravo. This time it worked. I was perplexed. It seemed to me weird. I did a lot of research on why this behaved differently when saved as a local html file. I had no more patience to try more combinations. I wrote a mail to Santosh asking what was the correct credentials. I briefly wrote about my effort. He got back to me saying the character looking like a blank space is a variant of space. He asked me to go to StartàRunàType Charmap and search for that special character and copy it from there and paste it in the username field. I did so and this time it worked. This evoked me to try the character which seems like a space but is not a space I was aware of. I pressed Alt+255 to generate that character in the username field and provided the password. This time it did work. I then confirmed that the character displayed in Charmap was same as the character obtained by pressing Alt+255. I was curious to know why when I did a “view page source” to the application and copied the space and pasted did not work. All these time I was using Firefox. I thought of opening the application in IE. I opened it in IE, did a view source, copied the entire source code and pasted in notepad. I then saved it as a local html and try the “no-break space” and “testing” combination. It worked perfectly fine this time. Copying the source code from firefox and saving it as a local html file didn’t work but with IE it worked. From this I drew a conclusion that firefox was not able to display the “no-break space” character. It was displaying it as a blank space. I do not know whether it is a limitation of firefox to be not able to display the special character and converting it into a blank space.

There are few things I learned from this exercise. They go as below:

1.      Analyzing the code gives an idea about how the system works. If some part doesn’t work properly, by looking at the code we can deduce the possible reason. In order to do so, we need to have the basic understanding of programming.

2.       Something which looks like a very usual thing (No-break space in this case) may not be that thing in reality. So if we have to think of other possibilities of what that thing might be. Having an earlier knowledge on “what that thing might be” can be very helpful. Though in case of unavailability of prior knowledge, we should be able to figure out a way to find it.

3.       Trying the same process in different environments or browsers for that matter, many new things can be discovered about the application as well as the environment. In our case the inability of firefox to display the “no-break space” in the source code.

Is QUALITY all about customer’s need and satisfaction?

In our organization, we (testers) have made a point to discuss on a weekly basis about testing, what we do at our work, what we do to test better. Besides, we discuss the possible ways of acquiring knowledge on this craft. We learn, unlearn, and relearn. We argue, we agree. Sometimes we fight to impose our own views on others on certain things. To justify self, we learn more about those things and resume the argument (fight rather). Sometimes we give up without any conclusive decision on whose views were more appropriate and applicable on a particular context. We keep our own views with us and move ahead. But never have we given up our discussions or fights for we enormously get benefited from these. 

On one such occasion, I and one of my colleagues had a long discussion on whether “Quality is all about customer’s need and satisfaction”. Not until we saw a bunch of people gathered at our cubicle to listen to what we’re discussing we realized that we were literally fighting. And unfortunately it was such of a few occasions when we give up our fight. I was against of the view that quality is ALL about customer’s need and satisfaction. She was for it. Actually she had prepared a set of questions for the new joiners in our team. One question was “What is true about Quality” and the correct answer (as per her) was “It’s all about customer’s need and satisfaction”. I was given to correct few papers and the moment I saw this question, I was surprised. I didn’t buy the answer. I called her to ask her views on this. Below is the conversation of mine with her.” I” represents me and “S” represents her.

I:  Do you really think Quality is ALL about customer’s need and satisfaction?

S: Yes, I do.

I: (reiterated the question)

S: Of course it is. What else do you think quality is?

I: What about a case where your customer is not the user? (By customer being not the user, I meant someone who pays us but has his own customers who’ll actually use the product)

S: I didn’t understand. Tell me a case like that.

I: Our client who pays us to build the product. But he is not going to use it; rather he has customers that are going to use it. The client is the customer for us in that matter. He might be quite happy with our work but the end user may feel unhappy using the product.

S: But by customer, I meant users only. So in that case, the end users are the customers.

Somewhere at my deep inside, I knew that it was not correct though I couldn’t at that point of time able to think of a situation by which I could convince her that quality is not all about customer’s need and satisfaction. I hastily searched my Skype to see who were online. Fortunately James Bach was. More fortunate I was when I pinged him and he responded in no time. I was on cloud nine since I knew that I was going to learn few things now. Besides, I was prepared to be amazed by his dexterity on “on-spot thinking of a situation to explain things”. Plus I was prepared to answer few of the questions I was anticipating I’ll be asked by him. That’s been his way of explaining things. You keep answering his questions until you realize you’ve got the answer to the question you’ve asked him. The discussion went as below:

I: Hi James

JB: Hi

I: Can quality be ALL about customer’s need and satisfaction?

JB: No

I: (whew, I was correct )

I: I even think “No” in case the customer and the user are different

JB: It’s not all about anyone

I: then?

JB: It's about the relationship between the vendor, the product, and anyone whose opinion of the product matters.

I: including testers, right?

JB: No, testers don’t matter.

I: who are the people then whose opinions matter but they aren’t the customer?

JB: You tell me. It depends on the project. But testers do not matter. Testers are agents for the people who DO matter.

(Then I was amazed by his dexterity I was talking aboutJ)

JB: Let's say you are selling pet food. The customer is a human. Their opinion matters, because otherwise you won't have customers anymore. But the government may matter, too. If there are laws about what can be in pet food; and the pet may matter... because if the pet refuses to eat the food, the customer will not buy more of it.

I: Oh yes, probably that's why we need to meet industry-specific standards.

JB: plus, if your pet food is found to contain toxins, the pet may love it, but pet lover organizations will go after you. So there are various stakeholders whose opinion matter.

I: True.

JB: One of your jobs is to figure out whose opinions matter.

I: Thank you so much, James.

I then conveyed it to my colleague. She seemed to get impressed but to justify her own view, she asked “if there are already rules to dictate you what not to do, why would you do it and hence ruled out the government’s role in pet food case”. I preferred to keep quiet for sometimes it is best weapon to use. But I had already learned a big lesson that “Quality is not ALL (all big case) about customer’s needs and satisfaction”.

The T&D relationship

People who are into IT field are well aware of a very popular relationship; a tester-developer relationship. And presuming that people who are reading this article are into IT, let me not describe the relationship in details. Rather lets dive into why this blame game is perpetual and what can be done to reduce it, if cannot be eradicated fully.

A tester is supposed to judge the quality of the work done by a developer. Wait a minute, here lies the root cause of all discussion, all this sensibly nonsensical blame game or war would I say rather. I am a developer, I am intelligent and smart and geek and self-respected (does not being a developer itself prove that I have all these qualities? I bet this does). How heck is this that a tester (now guess being a tester proves what and what) will raise questions on my work; who literally could not have been written a part of the code that I have written in his whole lifetime. I am not going to accept whatever he’ll say. We have a word in English which expresses this feeling; yes you got it right. It’s EGO. And in this context it’s DEGO, a developers ego (you can forget the term DEGO, I have no intention to add more buzz words to the ongoing term-coining-competition). 

On the other hand testers have also an ego, a TEGO. Some might call it as blasphemy to say so as I belong to testing fraternity. But that is the truth. A tester’s ego hurts when he is seen as an inferior to the developers. And how would he retaliate? By reporting more and more issues and in that way he can prove his superiority over the developer. In a way it seems good as the number of defects found will increase. But the number of defects alone is not the synonym of good testing. The issues reported should be valid and the way it is reported is another important factor. A tester who is obsessed with the aim that he has to prove the developer inferior has very less time to focus on the quality of the issues he reports. And he ends up reporting whatever looks suspicious at one glance without rechecking it the second time. Sometimes we need to change the setting somewhere to see a correct result for an event. But we don’t do the settings work, get the incorrect behavior of the application and report it as a defect in one go and hence eat up a good amount of time of others rechecking it. And the level of bitterness in the relation rises up.

Now, what could be the possible solutions to curb the battle? Once we sort out the root cause of any problem, the solution is not miles away. Following things can come handy to maintain a healthy relationship among testers and developers.

To err is human: This is the reason why testing comes into picture. We make mistakes and this is what we do our best, don’t we? And it is very difficult for us to find out our own mistakes due to lack of objectivity. And we need some other person, a tester to check it. This is as simple as it. Testers are not employed to prove that whatever a developer has done, he has done it wrong. They just help a developer doing things correct. And at the end of the day when a product has relatively less issues and performs well, credit goes to developer, right? Then why not thinking that a tester brings credit to a developer by questioning his work and he is not an enemy, a friend rather. Just imagine what have happened if your parents had not judged every action of yours since childhood. If they had not taught you to discriminate between right and wrong. Would you have been here where you are now? And are your parents’ enemies of yours? They were constructive critics. So are the testers to the developers. And a critic is the father of a craft and the craftsman the mother.

Testing is a part of development: Many often make the mistake to segregate testing from development. They divide software engineering into two parts; software development and software testing. And hence they think testing as a redundant activity for a software development process. Many developers think that they can test their work and don’t need a tester. I have heard many developers saying they find more bugs in the system than their testers do. Here is where a tester loses respect.  In fact, testing is a part of software development. It provides information about the quality of the product and process. It helps producing a qualitative product and hence is equally important. The day developers start respecting testing and testers, we are in a better world I bet. Again developers, give it a thought!

If development (as they say) is primary, testing is not secondary: Many think that development (in reality, they mean programming or coding) should be our primary focus as it yields the product. Who cares about the quality? It’s a secondary thing and we’ll focus on it if time permits. And the irony is some organizations share this view. They underestimate testing and testers and boost the morale of the developers. They instigate them to feel how unwanted the testers are for them. But quality can never be compromised; at least you cannot afford to compromise it. Organizations/Managements, it’s worth of a thought, for your better sustainability!

Testers are bug-warriors, not developer-warriors: As mentioned above, when a developer underestimates a tester’s skill, the tester becomes ferocious and reports vague incidents. Incidents which are not worth investigating. But this not a way to prove the skill or retaliate. You can never leave quality apart if you want to show your skill, can you? If you really prove that you have skill, test the application rigorously, if something seems suspicious, recheck it twice or thrice. If it still persists report it. But report it in such a manner that it gives enough information about the defect and the way to reproduce it but yet being precise and succinct. It becomes easy for the developer to debug and fix the defect. Ease of work makes them happy. And happiness creates a healthy relationship. Testers, just a thought!

These as per me are the main reasons behind an unhealthy relationship between a testers and developers and these can be pretty much worked out to improvise the relation.

Nature of job I am into: Perceptions of mine, other’s1 and other’s2

It’s been quite a long I was thinking of this article. Since I call this blog a testing blog, the job I am into is certainly testing. But what does nature of testing mean here? And moreover, what are other’s1 and other’s2? To simplify it, it is the nature of the testing job i.e. testing’s what and how about. Other’s1 here is the group of people who support my thoughts and views or it would be better to say that I follow their principles of testing and hence most of my perceptions, if not all would implicitly convey theirs. Other’s2, on the other hand are group of people who carry different perceptions from I do and I call their perceptions as misconceptions and I have reasons to call so. Surprisingly some of the testers fall on this group. I’ll discuss about them.

The key insight of this article would be addressing the myth that Testing is just another easiest job in the world. This perception about testing is ubiquitous. Everybody believes that anyone can do the testing job. They give reasons that they think support this myth. I’ll put their perceptions as MythX and my perception as FactX. So let’s go to the battle of Myth vs. Fact.

Myth1: Simple graduates (hence anyone) can do testing but not development: Why simple graduates are being hired for testing and not for coding or development (I swear I don’t know why they refer to simple graduates, don’t they have any dignity?). Because testing is easier than development and anyone can do this job if trained, or sometime they don’t need to be. Development is quite a difficult task and it needs geeks and genies.

Fact1: Every job in the world is just another easiest job provided you are passionate enough to doing that. Piloting a plane can’t be an easy job for all because Jessica Cox could do that without having arms. She could do that because she had passion. Simple graduates are hired because testing needs skill and to have skill you don’t need any technical qualification. James Bach is a high school dropout and still he is one of the best in testing community. Now would you say that if James Bach can be a good tester, everyone next door can be one? I would say yes but they have to have what James has, passion to test!  And I bet everyone next door can be an excellent programmer/developer, whatever you love to call it if they have passion doing that.

Myth2: If someone can’t do development, put him into testing and he’ll manage to do a decent job: I have heard that some company pull resources from development and put them into testing because they were inefficient at their work. How heck is this if it is true. And the irony is they call it degradation. They believe that inefficient people can’t make a quality product but they can judge the quality of that product.

 

Fact2: Probably we are very good at judging other’s works if at all we are unable to do that, ain’t we? This is why we suggest Sachin Tendulkar about how he should have played a shot sitting in front of television even if Henery Olonga would get us out every time he bowls to us. Probably from here we draw the conclusion that people who can’t make a quality product, they can easily judge the quality. Now for organizations who believe they did a great job by putting inefficient resources into testing, I would say they don’t really mean quality. If you don’t respect quality agents, you are simply not achieving quality. I would like to wish them luck for their future endeavors, if at all they have any future! And I would recommend them Moolya, the tester’s heaven if they can learn from them anything on quality.

Myth3: A tester can get involved in many projects, a developer can’t: There are instances where a single tester is assigned to more than one projects and he manages to work simultaneously. Developers are dedicated to single project. This proves testing is easier than development.

Fact3: I don’t say assigning a tester to more than one projects is bad. It is not only when the process is not hampered due to lack of time and obsession and compulsion due to many projects at a time. But there is no reason why the process wouldn’t be hampered. If any organization is following this, they are not serious about the quality. They are compromising quality. What I believe why they give more emphasis to development than testing is, development is the process where the product is made. “What the customer wants” becomes more important than “How the customer wants” for them. They think if they can deliver what customer wants, they can convince how they wanted it, who sees it after all? In a way, they are simply cheating the customers.

There are many other myths and facts but it will increase the length of this post and there was a chance of you not reaching the point you are reading now, but I am happy with the contents of this post for at least you find it worth reading till this point.

Let me announce that I didn’t want to prove any superiority of testing over development. Both of them are easy and yet difficult, only the perception differs.

Oh yes, I said that some of the testers fall in the other’s2 group. Really they do. And the reason is they take the myths seriously and are ignorant about the facts. Another reason is they dreamt of becoming developer but they were put (yes, you read it right PUT) into testing and they can’t fight for their dreams because they know they are not capable of winning it. And if you ask a simple yet vital question to such kind of testers “why testing is needed by testers?” answer like “it is because developers have not enough time to test it” is obvious. Pity that you have not given a chance to follow your dream, but the thought that you are contaminating the testing community being here is what kills me. Escape as soon as possible.

That inspired me to write!

This is my first post in my testing blog and i am thrilled to say that i have drawn the inspiration of writing about testing from two of the finest testers of the world, James Bach and Pradeep Soundararajan. I had a passion for writing about things much before that, in fact i wanted to be a writer!!!  I started following Pradeep’s blog few months back. In one of his posts why testers should blog?, Pradeep describes many good points about writing. It was no new fact for me that writing helps us in several aspects and Pradeep did not teach me that, but he certainly did inspire me to make the first move towards writing and i thank Pradeep for being my (and many other's) source of inspiration.

I have James Bach in my friend list in Skype. One day i pinged him to thank him for the things i have learned from his blog and his talks and the discussion goes as below:

Me: I wanted to just thank you for the lessons i learnt from your blog

James: cool

Me: I aspire to meet you someday, but before that i would like to deserve it

James: okay, well here's how to deserve it: test things. think about how you test. notice something that you find puzzling or interesting. write about it. That's how you contribute to the community

The discussion continued. But the reason why i posted these few lines is it taught me two nice things (read the words in bold). First , i should write about things that i find puzzling and interesting and second, i should contribute to the community (testing community). What a noble thought!!! We learn a lot of things from blogs, talks written and given by experts. We learn because they share. So now it is our duty to give back to the community and we can do it by sharing our experiences and thoughts.
 
So here i take a vow to share all my experiences and thoughts which i think will serve the testing community in one way or the other or atleast it serves my purpose of not forgetting things that i have already learned!!!
 
Keep putting the url of my blog in your brower :)
 
P.S. I am a novice writer and may commit a lot of mistakes in terms of spelling, grammar etc and i may not be able to make my posts humorous enough for easy reading but then i take another vow to work hard and improve these skills post by post.