Sayonara 2010 - Welcome 2011

2010-It’s been quite an eventful year, both personally and professionally. Year started with something quite probing i.e. testing a middleware application in a span of 5 days. I was asked to test the Service Layer part of the application and I am glad that I did it as I got to learn few more tools like SOAP UI for WSDL and RESTful web services testing. If 2009 was about learning RapidSQL then 2010 was about getting comfortable with DBArtisan. There has been some addition on how to use BPT or Business Process Testing using Quality Center and Quick Test Professional both from HP.

In last 4-5 months; I got to learn about iTKO LISA Test Automation tool which I found good for middleware and back-end test automation (or Automated Checks). It‘s not easy to use for sure, at first it looks like a configuration management tool and to make learning little difficult, a newer version of this tool does not provide updated version of help documents. I hope going into New Year; the tool owners will improve on help documentation because if they are looking to have a large user base they will have to help users and make them feel at ease with LISA.

Then there came Agile and for first 2 sprints I was kind of confused so I picked a book titled “Agile Testing: A Practical Guide for Testers and Agile Teams” by Lisa Crispin and Janet Gregory. It proved to be of immense value and helped me BIG time. So, now I have the experience in Agile environment (/methodology) as well. Few things I really liked about Agile are quick feedback and less documentation. In few weeks, I’ll put a separate post on my experience with Agile as a tester.

These are the few important things that I learned in 2010, more importantly I networked heavily and read a number of recommended books from James Marcus Bach. I hope to finish reading (& learning from) all of them by end of 2011.

There had been some disturbances as well on personal front but all is well that ends well. I am sure to start 2011 with a bang; a lot of things will change with the start of New Year on both of he ‘P’ fronts. I hope to network with lot more people in testing arena and share & learn with them. Ohh yes, I have few New Year resolutions also, I will blog more frequently then I have been doing in last 1.5 years. There are few more that I’ll not talk about.

Wishing you all, a very happy & prosperous 2011. This is Rahul Gupta signing off for 2010.

C Ya!!!

Will Moolya redefine meaning of "Value"?

A few days back, Pradeep Soundararajan officially launched Moolya Brainual Software Testing Services Private Limited on his famous blog. Moolya means Value. I was one of the few people who were aware of this development for at least 2 months. I got an opportunity to meet Pradeep at this year's GTAC in Hyderbad. So is it another software testing company that promises big....NO at least not to me and many others who have been following Pradeep's blog for over 2 years now. 

I am not an expert to talk much about business opportunities, market conditions and services offered etc. but I certainly know that there are so many money spinning machines in the world of software testing. You think of something related to software testing and few names will popup in your head, here is a simple exercise; Certifications in Software Testing, Easy to use Automation Tools, Quality / Standard Certifying boards (think of 2 names for each). See, you would rightly guess few names there. 

I have visited Moolya's site many a time since it's public appearance. Every time I visit it, something or other innovative (read different) approach becomes apparent, whether it be it's hiring process or the header of About Us page which boldly says "Curious to know about us?". 

I spent considerable time in thinking about this venture of Pradeep and Santhosh. It looks promising on many fronts because I feel a fresher will not spend too much time in mugging up some definitions, it will be like learning on the job and practicing that learning on Weekends; because I believe that people will not have managers who will ask them to go for some sort of certifications to prove their worth; because people will not spend hours in filling up excel sheets for some irrelevant metrics to prove test coverage ( or branch coverage and line coverage) rather they will win Clients' confidence by making them aware of current health of the project. I can go on and on for hours....but it's all not gonna be a bed of roses because Moolya promises to be a change agent and it will face some challenges from different quarters, I am expecting few anonymous bullies to comment on this post but that may not happen as BugMagnate is not a famous blog.

Pradeep has put a lot of emphasis on culture of the company and he said “They are the Microsoft & Apple of 1970's. They are the Google of the 1990's.” I don’t think any parallels should be drawn in terms of where it is starting because when any of the aforementioned companies started they were unrivalled in their market segment, the same cannot be said about Moolya. Moolya will need to collaborate, share, make it’s presence felt and above all It has to have a solid client list.

So what's gonna work in Moolya's favor at this point? Word of Mouth...yes and by means of this blog post I am starting in that direction. Let’s spread the word.

All the Best, Pradeep and Santhosh…I wish one day I’ll take pride in saying, “I know one of the founders of Moolya”. And I am sure; Moolya will prove Moolyavaan (of great value) to entire Software Testing industry and will redefine the meaning of "Value".    

What to Blog about?

I have been little confused for last few weeks. I seriously wanted to write something but was too much occupied with work and at the same time, I could not think as what I should write about? I am not sure if any of the bloggers whom I follow, face the same problem.

I wanted to participate in BlogSTAR competition of EuroSTAR conference this year but I could not make genuine progress on that front. And when the list of finalists was disclosed, my name did not figure out there. I understood that I didn't have enough credits, reputation or number of blog posts to prove myself a suitable contender for the coveted competition. No regrets as I got to know few more people in the software testing field. I do make a point to read all the posts on a daily basis and comment as and when I feel the need or something that intrigues me.   

I am running short of topics. So I asked my friends and colleagues who are somehow related to Software Industry as "What they would like to read about testing in next few weeks?". The answers I received were really encouraging. People don't want to know much about definitions, they want to know as how testing is adding value to the organization? (seems like a typical management question.). They want me to share, day to day challenges that I or my team faces in testing, products of different nature. So after getting some inputs, I prepared a list of things that I would like to talk about in coming weeks.

There was one interesting input that I received from a guy who just started his career in Software Testing field.  

He said, "Rahul, you asked me to read blog posts from Michael Bolton, Dr. Cem Kaner, James Bach etc, but I find it very difficult to understand as what they exactly meant." I was kind of confused as that guy has very good communication skills both written and verbal. I asked myself, "Did I ask too much from that guy to do that too when he is just 3 months into Software Testing?" I didn't know that answer. I went back to that little chap and asked, "What's there that you find difficult to understand?". He replied, "I found few terminologies and ideas difficult to understand, like Heuristics". I understood where he was coming from. I faced almost similar difficulties when I started reading these blogs 2 years back. He asked for my help on understanding the things  that are not directly about testing but the knowledge gained can be applied to testing "the passion we share".  

Lets see what I can do to help him. 

C Ya !!!

Rahul

Test Environment to Production Environment

Many a time, I faced a situation when application under test; was working fine in Test Environment but when it is released to Prod Environment (to real users), it goes down.  There have been many reasons as why it happened; functional as well as non-functional.  Following some frequent prod incidents in one of the areas of work that I am aware of, I posted a comment on my LinkedIn Profile. The responses to this comment lead me to write this post.

My comment was “To Save Production Environment......We need a better Test Environment, ideally a mirror image of Production Environment.” I think one of the ideas of having a Testing team; is to Save the Production Environment from any failure whether it is functional or non-functional. There may be many points to counter the above statement but let’s agree that organizations spend a huge sum of money to be rest assured that the application will not cause any trouble once it is tested and deployed to end users.

What are the probable causes of Prod incidents?

No application works on its own. There are always some downstream and upstream apps as well. The incidents that I had experienced were a result of one or more points as mentioned below.

1)      Two interdependent applications are being tested separately in different environments (for e.g. QA and UAT), both works fine but when deployed to prod, all hell break loose.

2)      QA environment may not have the similar data size as in prod environment leading to performance issues specially when there are jobs running & supplying data to another job.

3)      An Urgent requirement change is deployed to prod assuming it would not affect anything else and there is no need to test. The change was urgent because business was getting impacted. Now, after deployment the business is severely getting impacted because of an untested minor code change.

There can be many more reasons for failure of application in the prod environment. The last one is the most frequent one for me.

What I meant by asking for a better test environment?

Environment where all interdependent applications work the same way (in terms of data flow, data size) as they supposed to work in prod.

I have faced situations where an application was tested in test environment, no issues found in UAT environment but when the application was released in Prod, there were some serious issues. When the Root Cause Analysis was done; it was found that when application was tested in QA or UAT; it wasn't receiving data from one of the applications, so integration was never tested. But in prod; the application started receiving data and BOOM. The problem as I see it was the communication gap between teams involved. 

An environment where the dataset and user base are similar to that is supposed be there in Prod.

An application broke in Prod because the data files it used to receive in Test environment were of size few KBs but once in Prod it had to receive files of size of MBs and it couldn’t handle the load. Kedar Kulkarni, a friend whose expertise is in Performance Testing, would agree to this.

In general, a test environment is shared by many applications so timely availability to different teams becomes an issue. In such cases, environment management becomes an issue. And it’s an irony that people, who want their prod environment healthy, don’t pay enough attention to their test environment which can be disastrous.  

Can a better Test Environment Save the Prod Environment?

My friend Parthiban disagreed with my comment as mentioned in the beginning of the post.  His idea is to have a stable test environment and then mirror the same to prod. Initially I didn’t like or probably understood this thought. Let’s evaluate;

If we can have all the interdependent applications stabilized in the test environment in terms of data dependency, data flow and data size than yes we can mirror it to Prod. If we can remove the problem of communication which is generally a result of ego clashes, yes we can.

I would request readers to share their views on the same and let's learn from each other’s experiences.

Job Satisfaction

I read a book Outliers from Malcolm Gladwell. It talks about why some people are so accomplished and so extraordinary and so outside of ordinary experience that they are as puzzling to the rest of us as a cold day in August. Malcolm mentioned 3 factors that define Job Satisfaction for an Individual irrespective of the field s/he is working.
Autonomy: You get a role in deciding what you do every day. Even if you might not always get decide exactly what you do, you can choose how to get it done.

Complexity: It must be an intellectually stimulating challenge. As the book states, it should “engage both your mind and imagination.”

Connection between Effort and Reward: The harder you work, the greater your income or recognition (at least eventually).

I found the explanation quite good. So if I were to map my understandings of aforementioned terms in my area of work i.e. Software Testing; what I should consider?

I started my career in testing in the year 2006 and now it is 2010 so thought of base lining this write up on the same.

Year 2006

Number of defects found: In the beginning of my career, the more defects I raised, the more satisfied I was but it’s no longer the case. The Quantity has been replaced by Quality.

Automation: I thought that I should know automation and should be aware of various tools available for the same in the market. But I realized that if you don’t keep a regular touch with these ever changing tools and methods, you tend to forget it and you fall behind.

Domain Knowledge: Initially I spent hours/weeks/months to understand the business function of the applications under test, not all applications require domain knowledge but it is always good to know the basics.

Certifications: Ohh that’s a pain point for many. I did few certifications and believe that it helped me immensely in knowing terminologies and communicate freely with colleagues / clients.

The above mentioned points now have broader meanings.

Year 2010

Where the gaps are: I realized that issues in software aren’t intentional. No one actually wants to make a faulty system. But we still find issues. For example; issues may be a result of lack of communication or information flow. Now, I try to understand the bigger picture, I like to question why something is being done in that way and why not this way if I know what is this.

Learning: It’s a continuous process. Initially I used to think, “If I clear this Certification, I’ll become that etc.” But it’s not the case, with time passing by one need to continuously upgrade his/her skills. This is the only way to stay in demand is to improve on your skills. This is a hard learnt lesson and till date, it’s the most important one.

A new tool, a new scripting language, it can be anything. But the issue that I face is, if I don’t use technical learning I’ll forget the simple menu options of the tool. But if I find a relation of learning with my current project that learning become long lasting.

How can I contribute? I am not a Know It All guy but there is nothing wrong if I try my hands on an issue (may be silently) so that I may learn something. My limited technical skills do not allow me to contribute directly in fixing all the issue but I get some idea for example, how to install something on my machine? What can I do to reduce the on boarding time for a new joiner, how to make them productive ASAP without overburdening them. Is the QA team beside me planning to automate a set of their tests for an application if yes than is there a way to learn something if time permits? Taking this approach help me in revisiting things that I haven't used in long time, like setting something in Quality Center or QTP. 

Now, let’s back to three points above…..is there a relation?

Autonomy

I started believing that no one gives you autonomy, it has to be taken. One can get it by building trusts with stake holders, developers and fellow testers. Trust coupled with hard/smart work with motive to timely deliver a quality product; will definitely give the freedom to do something the way you know, is right.

Complexity

We may not start with complex tasks in a new field but if we can prove our mettle in handling relatively simple tasks, we can do wonders. I hope to shine, if not tomorrow than probably day after.

Connection between Effort and Reward

Rewards can come in many forms. Rewards are a result of continuous improvement in the assigned task or it can come because of excellent work done over a period of time. I am not worried about rewards as of now; my biggest concern is not to lose my passion for testing, learning, writing and reading. 

Test Managers

A Test Manager is a person who monitors deliverables, who bridges the gap of client and test engineers, who works as a motivator and mentor and one who decides your ratings at the end of year.  

This is a very generic definition I could think of which may be incomplete and readers may have different versions. In last 5 years, my friends and I worked with many people at different levels and here for simplicity, I would (on behalf of my friends as well) call, all of them “Managers” who have more experience than us. Here, experience means, they started their software testing career before we started. We find this definition of work experience incomplete (or wrong) though it is widely accepted across the industry.

They all were different in their approaches, few were so much involved so that we felt like a bird caged in a small compartment, and they were all followers of micro-level management style while few others were completely aloof. Then there were some, who allowed their test engineers a complete freedom with periodic review of deliverables, say once in a week / fortnight as the case may be. I really liked to work with the managers of this last category.

Why I liked third type of Managers?

These managers were the ones who discussed the problems without imposing so many solutions on their resources. They allowed their resources to explore different approaches, allowed them to disagree with anything and listen to their inputs whenever they had one. These Managers were not so obsessed with test case preparation because they understood one fact very clearly that “Its not the test cases that will unearth a number of issues, it’s the tester who will do the job.” They were not too much worried about metrics in the beginning for a new AUT but they recognized importance of data that will be available after one round of testing. These were the managers who allowed their resources to learn new technologies and also emphasized on implementing these learning in day to day work wherever applicable. These managers were open enough to share the client expectations clearly and communicate them freely without wasting any time.

It’s not just positives with third type of managers, its negative as well. I personally experienced that when one is really good with his/her work, they tend to become perfectionist and that leads to aggression. Few of them were bit aggressive at times but that was ok because their aggression was just about deliverables.  

What was the problem with other type of Managers in our perception?

The Aloof ones were not involved with anything throughout the years but when it came to appraisals, they had all the time in this world to point 1000 things in their subordinate’s work. Fortunately, I never had to work with such managers but my friends were not so lucky.

The micro-managers were always too much involved. So involved that they never realized the problems their resources may have. This may sound a bit exaggeration but read on the following thing they never understood.

1)     Test case preparation is not as important as testing, during execution. We are not against documentation but stake holders should realize that not everything can be documented.

2)      Test engineers are the ones working on projects, trust their abilities to perform well, monitoring should be there but it should not turn into smothering at any point of time.

3)      Automation is good to have, but it does not make sense to completely rely on it.

4)      There are no Best Practices; one should understand a context rather than blindly following something for marketing at higher level. 

My friend's Story - Who should do the Automation & When?

My friend recently changed his job. He is a Software Tester in Telecom domain with good knowledge of things (Domain & Technology) and more importantly he is willing to learn, for him learning has no limits. And this is precisely the reason why I thought about sharing his story with you, as it concerns us all.

As we all know that whenever one switches his/her company, s/he has to first adjust to new working environment, new colleagues, new processes etc. Same happened with my friend as well. My friend was given a project / application to work on. The project didn’t have this QA function earlier and there were no documents available for my friend either. So question was where to start?

Well, a meeting was called with all the Stake holders and it was decided that the new joiner should undergo some Knowledge Sharing (KT-Knowledge Transfer) sessions to get some more knowledge about the product he will be working on. KT completed just after a single one hour session and my friend was asked to start writing test cases. The irony was, the person who gave this KT to my friend was also a new joiner and was a developer. For most of the questions asked by my friend, he didn’t have any answer and what can be the better excuse than saying “I am also new like you.”

Then somehow Test Case started coming in and there were hour of reviews by different stakeholders to get it correct. (Actually no one knew what is correct, as told by my friend.)Later my friend came to know that the test cases he prepared are to be used by some other team. That team will use these test cases for preparing Automated Scripts.

My friend wondered as he never did automation straightaway without executing at least one cycle manually just to make sure that application is stable enough to for automation. To worsen the matters, he had to conduct reverse KTs for that so called Automation Team to make them understand the functional flow of the Application Under Test.

My friend proactively offered a solution to his manager saying he can do a lot better job if given an opportunity to work on his own with a definite timeline. Manager partly agreed and party disagreed. Manager said, “You should focus on preparing test cases, leave automation to concerned team.” But at the same time, manager was also concerned with deliverables that were getting delayed because my friend (who was asked to just write test cases) was not just writing test cases, he was also executing, logging defects, attending calls, feeding automation team and exploring application under test all at the same time and these things remains unsaid but he has to do it.

This whole process required a lot of time and the result was neither test cases could be completed by my friend (who is still exploring the product to learn more about it) nor the automation team could completely prepare their scripts.

So, Who is responsible for all this delay? NO NO I should rather say What is responsible for this delay? My friend who was a Star Performer in his previous organization (because of his gifted skills in Testing and his hunger for knowledge) is a worried guy these days.

I could think of few reasons, I would request you to put few points from your experience as well.

1) Stakeholders should not have directly jumped onto automation to get more coverage; they should have first allowed my friend (a tester by destiny) to understand the application thoroughly.

2) If it was pre-planned that automation will be done by some other team, that team should also have participated in KT session. This would have reduced the Learning curve.

3) Taking parallel approach for automation and manual testing makes sense only when one knows what should be automated and what not that too when application is stable but not otherwise.

My take, stakeholders should think in long terms, consider the broader view. What do you think?

My friend is in need of your guidance, please share your thoughts.

Trading & Software Testing - Is there something common?

A true Story: Explained My Work i.e. Software Testing to my Father

When I started my career as a Software Test Engineer with a reputed company my father asked me what you do sitting all day looking at the computer screen. I said that I make sure that things (software) work the way it is expected to. And believe me it was difficult for me to explain my job because my father is businessman and IT is not something went down well with him earlier. Although he made a handsome profit after investing in some IT companies right in middle of Dot com crash...it did take some time before he en cash it.

Few years later, one morning I asked my father, “If you invest Rs. 500,000 in share market, in Share of one single company, do you see any risk (of making losses) there and if yes how do you minimize the losses?”
He promptly said, “I am not a fool to invest Rs 500,000 in a single company without considering Risks, the risk of losing hard earned money. Once I invest, it means that I have taken a Long position on some equity with a view that I will sell these shares after sometime when prices of this equity go up and thereby I’ll make profit. But as I cannot afford to lose all my money so what I do, I buy Put Option (buyer of Put Option gets a right to Sell underlying asset at pre-agreed terms and conditions to seller of the option.) to hedge my risk for a minimal premium (amount)”.

I said, “Papa now I’ll explain what I do. Software is developed with an intention to reduce manual intervention in things which we do in our day to day life and software does all this at a very fast speed. As a trader, earlier you were buying / selling shares by making a phone call to your agent and he used to do all the trading on your behalf, now sitting at home you can see price movement and buy/sell accordingly by using a Computer with Internet connection and having some Demat / trading account. Now if something goes wrong with your trading application (suppose it starts buying against your sell order) you might lose a lot of money.” He agreed to my delight as it made some sense to him.

Then I said, “As a software tester my job is to identify such problems which we call Defects and get it fixed by developers and again test before it is shipped to its users. A trader hedges the risk by Buying a Put option against the Long position s/he has taken on some equity. Though, not all traders do it and the reasons can be many. For example; Not a big amount of money is at risk and s/he is willing to take that risk of losing money ad don’t want to pay extra cost s/he will incur on buying a Put option for a premium. In market, if price of Share does not go down and market is offering more than what seller of Put Option is then trader will not sell his securities to that fellow and will let option seller keep his Premium (which s/he initially paid as an Option buyer) and sell the securities in the market for a higher profit.

Now implement this is Software industry. Company invests a good amount of money on developing the application and if they do not go for testing Risk of something going wrong increases so in order to hedge this risk the application owners ask for testing also.
By drawing this analogy I could successfully explain my work to my father and he agreed that I am doing something good.

A Thought - Why do Companies follow Conventional Testing Methodology

Since last few years, I have been working as a Test Engineer, testing applications of varying nature specifically in Finance domain. Moreover, my approach had been just like what I am told to do. For example; Write Test Cases (using some Test Management Tool), execute the written scripts and report bugs. At the end of day, send the Testing Status Report to stakeholders. Over the time I realized, “This way is not going to help me in longer run.” I had to do something to keep on learning and reporting some show stopper real bugs with an intention to make application better (less risky if not risk free) for the end users. So I started exploring things apart from my application like finding new ways to reduce cycle time (by means of Automation), report High Severity bugs etc and start questioning anything within my limits.

I asked that why we need to write Test Cases, when I know that this is not going to help. I knew that test cases are not covering all the functionalities because application is not a Web Based one; I am doing data validation and certainly cannot come up with generic test cases. I said Instead of wasting time on preparing Test Cases when I can put it in testing my application effectively.
Similarly, I asked questions on filling different kind of Test Metrics (DAR, CAR etc) which certainly do not convey any real usage. Someone replied that we use this data to benchmark ourselves with the best in the Industry and it helps us winning clients.

It still did not satisfy me completely because I knew that data is not always 100% correct. There is always some gut feeling involved. There is always some overlapping happening when we talk about SDLC or STLC. Everything is driven by money. In real life situation, money is allotted to project first and then the estimation is done whereas it should be other way round.

So, Why do companies follow conventional (Script based and so many processes) approach. This thinking lead to some questions-
Note: When I said Conventional, I meant following a plan in terms of writing test cases and doing script based testing all the time without getting much value, filling metrics etc.

Supporter of conventional methodology said;

1) How will you ensure that testing is complete if you don’t write test cases and mark their execution status by some means?
2) If after testing, a defect is found in Production (/Live) environment how would you say, “whether the underlying functionality was to be tested or there was some change in requirement which went untested?”
3) How would you measure Test Effectiveness in case you follow Exploratory Testing?
4) How would you measure and compare the performance of two testers as at the end of year, only one can be promoted or can get a better hike?
5) When one tester leaves an organization or project s/he working on, “How will you pass the knowledge if you don’t have things written? This is a risk area which has to take care of from company’s perspective.”

I could not find the answer to above-mentioned questions. I started reading some Slides made available by Cem Kaner (it was suggested by Pradeep from http://testertested.blogspot.com/ ) on Exploratory Testing. At one place, Cem mentioned "How to assess individual tester performance" under "Areas of Ongoing Concern”. This point acted as a trigger. I know Exploratory Testing is the way to go but still few questions remains.

I request readers of this post to please respond with your thoughts on the above listed points and help me learning.

Testing - A Career by Chance

I have been thinking to start my blog on Software Testing for quite sometime now. So here I am... I joined an IT company as a fresher close to 3 and 1/2 years back and since then I've been testing applications of different nature. I was a tyro in software field...had no knowledge of different terminologies and had zero exposure to different testing tools.

In an span of first 2 months, I recived rigorous training on all these thing and this training was then followed by testing a product (a dummy project). We as a team of 5 associates identified 27 issues (bugs/defects) with different severities. But one thing went completely unnoticed that we didn't have any reuirement document. Before we actually started testing the assigned product, one senior person came in and explained the functionality, work flow and basic objective of the product under test. That all discussion was never documented.

We divided the whole product in different modules and distributed the work among ourselves and started playing with the application (remember we didn't have any requirement doc, no test cases etc.)

All we knew was "This application would enable its end users to order something online." When we were playing with that application, one of us left his machine idle and when he went back to his terminal he found an interesting thing "Your Session Timed Out. Please Login Again."

WOW!!!! We thought that functional expert guy never told us about any such feature this application is supporting. We went back to that guy, asked him about this behavior, he replied "If you leave your machine unused for 15 minutes, application will automatically log you off". We thought of testing this and in each attempt we found "inconsistent" timings and this was the first bug we reported.

Then our mentor said, "you all guys are taking so much time to test this application, remember we have just 3 working days to complete testing". We asked him, "Is there a shortcut or a faster way to do this". He replied, "Do one thing, compell your application to do something that it is not supposed to." Bingo!!!!

Later I learnt the approach we followed was actually exploratory testing where we never followed any test cases or written scripts and it was effective as we could find almost all of the HIGH Severity defects.

In these two months, I explored an unknown territory i.e. Testing. People in my friend circle said, why did you opt to be a tester. I said, "I didn't choose testing, it has choosen me...probably I was destined to be a tester." I am happy that I was right. Moreover, it is difficult to produce the correct things but so far its not been that difficult to prove that the product is full of bugs.

In last three and half years, I cleared a good number of certifications on tools, testing and business (I am in Financial Services Industry). I consider myself as a learner in Software Testing field. I spend my free time reading things, exploring new technologies and always try to find a way to do things in a better manner. I am not sure how many people (from testing field) would ever read my post or would care to put a comment but one thing is for sure that I won't stop writing or reading things.

At last, thanks to two people. Parthiban Murugesan (http://testingattitude.blogspot.com/) and Pradeep Soundararajan (http://testertested.blogspot.com/) for encouraging me to start writing.

I am here to learn and share my experiences so far and will contribute to testing field in whatever way I can. Thanks!!