Monday, January 25, 2010

Should I report to work on the Indian Republic Day? or any Indian National Holidays?

Furious thought... resulting furious rantings and ramblings... I would never want to write about a non-testing topic, but try as I might, I am unable to put these thoughts out of my mind.

As I write these, a nation of a billion is celebrating their republic day. All schools and institutions have been declared a holiday. I am reading news articles about how people are rebelling against organizations that have asked them to come in to work on a republic day to meet client commitments and project deadlines. "Should I go to work on an Indian Republic day? Is it moral for the boss to call me to work on this day??? -" At the outset, it seems like a million dollar question??? Is it one??? Well, I would think definintely not!!! mostly because, it's not worth even a few pennies, let alone a million dollar...

To answer the question, "Should I work on an Indian Republic day? Definitely not!!! For god's sake, it's a NATIONAL HOLIDAY" seems to be every body's answer".. Well, the let's spend some time pondering over this thought...

Agreed that police, military, medicine and transporation are essential service? A quick checklist of questions for the same person who does not want to go into work on a Republic day.

1) Do you ask your maid to come into work on a republic day?
2) Do you get pissed off when you go to shopping on a republic day and find there are not enough shop assistants to assist? Do you complain to the shop manager about the lack of resources on a holiday?
3) Do you get angry when you find that your apartment security person has gone off to attend
celebrate republic day and is not into work on that day?
4) Do you get angry if you are watching a movie on cable on republic day and the movie conks
off? Would you want the cable guy to fix the problem immedieately or are you absolutely all
right if he fixes it after a day?
5) If there's a plumbing problem at home on the republic day, would you want to call the plumber immedieately to fix it or you want him to fix it later?
6) Do you plan to get the odd carpentry jobs around home to be completed on a republic day?
7) If you lose your ATM card, or if you have a problem with your mobile bills, do you expect customer service to be available on a republic day??? Or are you all right if they shut shop for the day and resume services the next day?

Sad but true -----> Sometimes, we as clients, or when we represent a form of the clients and show the inclination to have unjust demands. Similar to how we expect our clients to understand human sentiments, we would also need to understand human sentiments and have our expectations accordingly.

We show a lot of hypocratic tendancies wherein our expectations of people that we pay to serve us is completely different on what we want the people that we serve to expect from us. If the answer for most of those questions in the checklist is YES, then it means that we belong to the category of clients with unjust expectations. Thank god that you are not a client :)!!!

Fake Testers Gyan of the day ---> Please keep human sentiments in mind on National holidays!!!

Sunday, January 24, 2010


Hiya all,
Interesting thought. All of us would know that there does not exist any software product which is defect-free. Very true and accepted world-wide!!! Applying the same thought to life, it means that there cannot be a human being who cannot be always right. That means that you, the reader, ain't always right (you might just not agree with this - which means neither am i right - hypocratically speaking as I write this :))..... But this means, that your boss at your ain't always right either. But, who is going to tell him that he is not right?

Before going further, let me dedicate this post to all the "fake bosses"!!! Happy Faking!! :)

Dis-agreements with your boss is a common happenning at the workplace. It's not uncommon to find employees commenting on the lack of common sense of their bosses. I am very sure, if a survey is taken, more than 95% of people would find themselves in almost every day situations where they dont agree with their bosses. What about the other 5%? They would belong to the breed of "yes-boss"ers!!!

Some very common situations that I have seen where you would find that your boss is in the wrong and what to do then --- and a few drastically radical thoughts on how you can tell your boss that he's wrong...

1) Testing times - Let's give this guy, who's been with our organization for 2 years a promotion. --->
I have seen this situation happen so many times. Say there's a average performer in the organization who has worked with the companyfor 2 years. Though it is not worth giving him a promotion, bosses intend giving them a feel-good promotion. Sometimes, this would be highly depressing to the other deserving candidates since this guy, on the virtue of having served the company for a 2-3 year period, eats into the quota of another deserving candidate. Many managers have tried unsuccessfully to fight this situation, but this keeps coming up in 1 way or the other almost every appraisal cycle.
How to tackle:-
a. 1 way is to have a 1-on-1 with the boss to tell them that another person is deserving. But, this method usually doesn't work since the boss has an ego that does not like being told that he's in the wrong. So, you have to pacify the ego and try to push in this information.
b. Since the person is an average performer, it should be easy for you to compare him with a similar performer in a different team and tell your boss as to why this guy does not deserve a promotion.
c. Tell the boss that even if he is being given a promotion, then ask him to transfer this guy to a different team since the promotion would definitely affect team morale.
d. Put your promotion critera on paper and try to reason out with the boss.
What happenns mostly:-Well, mostly, the boss goes ahead and gives a promotion to this guy, and gives him a very little pay hike. Finally, the good performer feels that he's not rewarded and plans to move out. The rewarded performer feels that the reward ain't enough and plans to move out. It's a perfect example of a lose-lose situation, and mostly, you would be fighting a losing battle.

2) Oh!! That feed hasnt' been active in 8 months time. Don't waste time testing that feed --->
I have seen this. To cut-down on testing time, when the boss wants the code to go to market in quick time, they take a quick look at test cases and try to cut corners. Usually, people try to reduce test cases that get executed so that the product can be certified in quick time. An interesting case is in the case of feeds. Consider that there is a scenario wherein the product rates get fed into the system once a year. Looking to cut corners, the boss might make a decision to "not test" that part of the system, to reduce test timelines. This is just 1 example. What do you do?
How to tackle:-
a. Bring in the business analyst. Get the business sign-off stating that this feed will not be used and that this testing can be ignored.
b. If you feel that you would look like a "nut"case asking business to look into this, prompting business to ask you "dont you know even something as elementary", then try to take the boss through the system and convince him as to why this feature would be important for testing.
c. If you are very confident of your business knowledge, tell him taht the system would crash if it is not tested.
d. Try to locate business critical test cases and see if this case exists over here. You would have to dig into some old scripts.
e. Search the defect database to see if there have been any earlier defects in this area. If there have been, then this would become like a "potential cause of failure".
What happens mostly:-C mostly works :). The bit of telling the boss that the system would crash mostly works. What many people dont know that it is very easy for the tester to strike fear into the heart of the boss, by telling that if a feature is not tested, then that particular system would easily crash.
3) Oh... site ain't working with cookies disabled, is it? - no problems. Test it with cookies enabled and give the sign-off --- >
This has happenned so many times. As I write, I dont know how many places this is happenning at. Assume that the web-site does not work with cookies disabled, the boss instructs you to test all functionality with cookies enabled and give the sign-off. But that's just not testing, is it???!!! Well, the boss thinks that's what testing all about. The boss's business objective is to "ship code" in quick time. wait a minute... Shouldn't that read "ship QUALITY code"??? Well, some where in the test cycle, due to time constraints, QUALITY has gone out of the window :).... What do I do?
a.This is an every day situation. If the test team is really net savvy, they should have a list of other such projects where such bad testing has happenned. It should be easy for you to quote a reference.
b. Tell your boss that your fresher feels that this is a very dumb idea.
c. Have the project reviewed by the other people in the company who are tech savvy. They should tell him that this is not the solution.
d. Again, go running to business - Business users would never agree to this. If you have a very good business team, they would have the configuration and information about the end user browsers and their settings. Refer to this to make a decision.
What happens mostly:-All of the above 4 work and you would be able to stop the release. But, common sense dictates the presence of "idiots" in management. For the exclusive set of these idiots, they would want you to go ahead with testing with cookies disabled.
4) Why does the tester need to understand the software design? --->
A very commonly asked question. Not just by the development team, but even by some CEO's and CTO's... Why does a tester need to understand the software design at all? All he needs to understand business requirements to test the software. So, why would you want to waste time by having the test teams attend sessions with the design teams at all?
Well, it's a good question... My take... The tester would need to understand all the design workflows in teh system to design his test cases. A very simple example --- If a website is designed with values being passed as querystring instead of being passed as form values, then he shoould design his test cases to ensure that the system behavior is not altered when he tries to inject teh relevant querystring with his own values. This is just 1 example.
And, if you are working in an organization where the CEO/CTO question the need for understanding the design, please do not fight it--- just quit. Sometimes, quitters end up winners too!!!
5) Performance testing --- Why do we need it if the client says that he doesn't? --->
Another every-day happenning. Hey, the client feeels that we do not need performance testing at all... Why are you planning to do it? The client is always right, ain't he? If he doesn't want something, dont do it... Go ahead and deliver just what he wants!!!
My take --- BOSS, the client is not always right. When you go to a doctor, the patient does not say what he wants. The doctor does the diagnosis and treats the patient accordingly. When you go to a lawyer, the client does not issue the diktats. It is the lawyer who says what needs to be done and advises the client of all options. In this case, if you are doing a website receiving regular feed, doing regular refreshes, etc.,, then it's highly likely that you need to do at least 1 round of performance testing before go-live to predict how the system would behave today and after it goes up to a certain level (scalability tests, etc...). It is your duty to convince the client as to why he needs to do performance testing. Tell him the reasons as to why you need to do performance testing and from your organisation's project archives, pick up the list of projects which have failed due to lack of performance testing and present it to him. Work with him to understand how you can do performance testing parallelly so that timelines will not be hindered and I am sure, he woudl agree to the same. Budget problem, again escalate... But never tell the client that he can go live without performance testing, especially if you do a project review and find that there is a need for performance testing.
6) 2 days for go-live and want to fix a defect? Sure go ahead, we can complete testing and release --->
More of an every-project happenning. In 75% of the projects, there exists a situation where the business has a requirement that is born with 2-3 days before project release. This assumes the highest order of priority and very soon, the boss finds himself telling the clients that this last minute change can be accomodated. After all, the customer is king, ain't he???
But BOSS:-
But, Boss, the customer might be a king... but please read the history archives to undersatnd how many kings have lost their kingdoms due to having a very bad ministry team? Akin to the ministry team, the business will always place a lot of pressure on making last minute changes. But, as a tester, you will have to highlight the risk. A simple cosmetic fix that comes at the last minute might cause the heart of the system to break. A very simple javascript fix would cause an inability to login. Sample this - someone wanted a date-of-birth field to be added with 2 days to go live. The programmer, injected a defect wherein the date-of-birth went and over-wrode date-of-registration on the website. So, when the website wanted to generate a report to reward long time subscribers with 100 points per year, imagine their surprise when they learnt that they would go bankrupt, if they were to fulfill their promise to their customers. This is because, the report took into consideration the date-of-birth of the customers instead of their date-of registration. For someone who would earn only 100 loyalty points, the site said that they would earn 4500 loyalty points... All this happenned because of a last minute release.
So, never ever agree for a last minute change. The boss might pressurize you saying that you need to be more flexible, etc, but please remember, common sense takes priority over everything. Negotiate to make the release as a patch release sometime in the next few days, but never agree for a last minute release if it does not fix a defect.
7) Test Estimation can never be more than development estimation --->
Not many know that this is a myth. A commonly held belief of the fake tester... So many companies have this - They split requirements as 10% of project effort, design as 10%, project management as 5%, development as 30-40%, testing as 25% and UAT as 5%. More often than not, as a tester, you would find yourself into a project with very minimal estimates for testing. People, more often than not, do not think that a tester would need time to understand requirements and design. They think that on Day 1, he can start scripting for test cases, create test data and test it in quick time.
What do you do:-1 thing that comes to mind. Always ask for additional people. Try to create your own estimation mechanism and if you feel that the project estimates do not match your estimates, reason it out with your boss showing him valid data on time taken to create test cases, test data and test execution.
What do you do if the development tell you that test teams are longer than development? Some examples...
a. If the developer is using a framework, that reduces his development time. But that does not mean that a tester should refrain from testing his business requirements.
b. Like a code review, test team would need ot undergo a test plan review and a test case review. Testing is a parallel activity and it is not possible for test estimates to be containeid within overall project estimates.
c. Testing time would also include application setup, and more often than not, the 1st build that you receive would not be working. You will have to accomodate for these timelines also.

8) Original software for automation costs a million? Well, go ahead and use a pirated version just this once. Who would know about it? --->
This is something very unethical. A true tester would never ever go down this path --- It's better to be without a job, than do something "unethical". It's similar to commiting rape or a murder. If you are a rapist or a murderer, then go ahead and follow your boss!!!
9) All the valid reasons where the boss's right --->
Well, its not that the boss is always wrong. So many times, the boss is right. I have had the pleasure of working with so many bosses that I have looked up to. Sometimes, the boss might be wrong... and sometimes, you might be wrong too. The boss can be right more than once, and... after all, he's the boss coz he's been doing the right thing most of the times. So, please do keep in mind that the boss might be right. Always evaluate the complete situation before deciding on what action needs to be taken.

Always remember... there's 1 differentiating factor between the real tester and the fake tester... The true tester would know "what to expect from fake bosses" and have plans in place accordingly.

And what happens if all the above fails? A true trait of the "fake boss" is that they would believe whatever they find on google!!! They also have immense trust in whatever info they find on our blogs!! heh heh.... So, all you have to do is to give them a link to my blog and I am sure you would find a solution!!! :)

Well, the above is just some instances that I have seen happen around me. A few of my friends also experienced somme of these situations. Few takeaway points --- just because that you are the boss don't mean that you are always right. Please rely on common sense to determine the person who is correct in these situations. Time, Quality and cost are vital parameters that a test manager would need to rely on for decision making to ship software. Anyone who does not rely on these parameters, like me, is what I would call another "fake tester"!!!

Thursday, January 21, 2010

The Artistery of UI Testing - Part 1...

Hi Again...
Today's rapid random ramblings - Completely about the art (rather, artistry) of UI testing. Well, why do I call it the artistry of UI testing? To term it simply, it is an art. Spend a few minutes thinking about it - dont you feel that it's similar to how Sachin wields his bat, or Federer wields the tennis racket ? UI testing is simply an art, mainly due to the various kinds
of scenarios that you can come up with while you indulge yourself in the "art of UI testing". Nothing gives me greater pleasure than UI testing, but nothing gives me greater pain since every tester thinks of himself as a UI tester.

To understand more about my take on UI testing, let's try to define UI, before understanding "UI Testing"!!!

Definition of UI
An interface with which the end user can connect to the system/applications.

Well, in an earlier world, this was known as GUI (Graphic User Interface). The success of Microsoft Windows the world over has made it unimaginable for our current generation to even imagine a non-graphic user interface.
The way I see it, the best way for UI testing would be to create different classifications of testing and plan the test cases accordingly. My take on UI testing would be to classify UI testing as 1 of the below:-
Accessibility, Alignment, Appearance, Compatability, Data Validations, Date field validations, Error Handling, Hot Keys, Menu Validation, Application navigation, Security, Style sheet validation, Toolbar related scenarios, UI related scenarios and All other validations.

Before I proceed further, UI testing will be completely different for windows applications and web applications. This is mainly because, a windows application is completely owned by the development team, while a web application UI is somewhat dependant on the browser. For example, I will be able to write an application and have total control of it's UI if it's windows-based, but I will have to keep in mind the browser specifications while thinking of a
web-based application. Some of the items applicable for windows is not applicable for web and vice versa.

Now, before you proceed learning, please keep in mind that I subscribe to the same thought works as that of the fake tester and that's how this list has come up. This list is always debatable.

If you know Ratatouille, you would agree with him when he says "Anyone can cook". Likewise, the truth is that "Anyone can test"!!! Really, I mean it. But, again, like how cooking is an art which has been perfected over years of practise, testing is also an art which has to be practised before it can be perfected. As initial steps towards this journey, let's take a good look at the A's of UI testing.

What are the A's? -- Accessibility, Alignment and Appearance :).

The way that I define accessibility - in layman terms, the applications should contain the ability to allow everyone to access the page (even a blind person). If there is an audio output in the page, the application should have the capability to allow the deaf to be able to hear it when they access the application. For example, some users would be color blind too. That would mean that the colors (green, red, etc.) should not be used for highlighting purposes in the screen.

Alignment is the alignment of the screen and whatever you see on the screen. Now, using the browser, it would be possible for you to increase the font. Using the windows properties, it would be possible for you to change the screen resolution. Whatever be the reason, the expectation is that the application alignment is not changed and remains the same. It would be a good idea for the user to check for constant spacing across the application.

How does the application appear on screen? That is what is the meaning of appearance. Check for the size and font of all command buttons, all radio buttons, etc. used across the application.Check headings, the beginnings of the list boxes, beginning of paragraphs to ensure that whatever is given here makes logical sense.

While we are on the topic of UI testing, to answer 1 common question - is it a good idea to automate UI testing? Yes it is (more of it on another day)... But, 100% reliance on the automation process for testing the UI is a bad idea. You would need a person to test the UI.

To summarize, While it's true that whatever you do with the UI becomes, in 1 way or the other, a UI test case, it's imperative that the tester would need to understand the different classifications of UI and try his testing cases accordingly. Every tester who does not do this, in my opinion, a true "fake tester" :)!!!
See you later...

Sunday, January 17, 2010

What does the species of Technical tester try to achieve? Do we need him at all?

Few more thoughts resulting in a bit more of gyan --- "Technical Tester"... This seems to be the buzzword going around. I have heard countless teams and managers complain that their test team is not technical enough and every one feels the need to build that bit of "technology awareness" to create technical testing teams.

Well, at the outset, if I am to have a bird's eye view of the large picture - today's Indian engineering colleges manufacture graduates and while half of them end-up as developers, the other half ends up as testers. Today's project management world has effectively created the abillity to classify each member of the project team as a developer or a tester. (Though the Business Analyst, Architect, Project Managers are also a part exist in the team --- they are
mostly looked more as developers or testers for a most part of the project).

Now, I dont see anyone asking around for a "technical developer" (while everyone are looking around for a "technical tester"). To share with you, a few bits from my memory on my perception of a technical tester and as to why this problem is so much prevelant in today's world....

I truly believe that the prime fuelling factor for launching the birth of the requirement of a "technical tester" is the present lack of Technical Developers in today's world.
Though most of you might not agree with me on this, and the statement can become highly controversial, I believe that our search should also be for a "technical developer". To understand more on this, let us try to see what we want "ready-to-test" code to accomplish and what it actually accomplishes, in most of the cases today.

What does "ready-to-test" code expected to accomplish?

A few points that come to mind immedieately are as follows:-

1) Ensure that the current requirements are met.

2) Ensure long term scalability

3) Meet all security conditions, so that the code cannot be hacked

4) Ensure that all security breakages that the technology cannot do is done by the sourcecode

5) Ensure good performance of the source code

6) Meet the obvious boundary and negative test conditions

7) Ensure that there is no existing feature that is broken

8) If any reusable component has been built and can be used for the solution, ensure that this component is consumed by this solution - Ensure that the wheel is not re-invented.

9) Effective usage of logs for logging appropriate errors

10) Good exception handling techniques for error handling

11) Good coding techniques to handle deadlocks, (wherever applicable)

12) Effective usage of the programming language (for example, in .NET, usage of the string class for string concatenation instead of the + operator)

But in reality, What does today's "ready-to-test" code available for the testers actually accomplish?

In most of the cases, the source code would just meet the business requirement. Most of the other issues would be swept under the carpet and will not be available in the first build that is available for the testing team. The problem statement is that today's "ready-to-test" code that is made available for testing does not even attempt to fix most of the other problems.

Looking at the above, I am of the opinion that more than 75% of today's developer community write code to fix the business problem, without worrying too much about security conditions, performance, scalability of the application to grow over time, writing code for the satisfying simple memory management requirements, or even satisfy the simplest of negative test conditions. Today's developer community have complete lack of understanding of an operating
system, how the programming language interacts with the operating system and about other features of memory management.

But, surprise surprise!!! the tag of a "non-technical developer" is not bestowed on them mainly because of today's critical project deadlines, and the beautiful ability of our project management teams to turn a blind eye to all these attributes that cannot be seen. If the code solves the problem, it is given to the test team as "ready-to-test" code.

What happens when this code is available for our tester?

Now, the tester, sharing the same background as the developer (he would also have been from the same college or training institution), and with the same knowledge as the developer, will turn a blind eye of not testing these conditions that cannot be seen. Now, when some client or user sees some such condition as above, they term that the test team is not technical enough and the entire project management team starts their focus on the technology training of the testing team, whereas the problem to be solved lies elsewhere.

What is a Technical Tester?
Few more on my thoughts below on what is a technical tester...
1) Just a normal tester - There is no thing as a technical tester. What we mean by a technical tester is a true test practitioner who understand both the business and hte technology.

2) Someone who understands the business context and the domain - It is very important for the tester to undertstand the business domain of the project. He also needs to understand the business context. What is the business context? That is the fundamental reason as to why the project is being executed in the 1st place. When the business context is understood, that will go a big way in prioritizing his list of test cases.

3) Someone who understands the technology - It is very important for the tester to understand the technology on which the business solution is being built. Every technology has a lot of advantages and dis-advantages. For example, a solution built on the Microsoft .NET platform need not be tested for memory management (since the technology takes care of most of memory management), while the tester would need to write scripts to test software built on a pre-.NET platform for memory management. The tester needs to understand the technology, and write effective test cases to ensure that the software code also closes any gaps which are still unplugged in the technology, apart from cases to test the solution.

4) Ability to write code for testing - A true technical tester would understand the different ways available to test the software. He would not rely just on the UI needs, but will also be able to write simple code to test the application.

5) Ability to breach security - Now, I am not saying about his ability to breach the networking security layers. But this is more about his ability to breach the security holes offered by lack of coding in the source code. A technical tester would be able to go through the source code, have a good understanding of the programming language and should be able to design test cases to break this.

To summarize, we would need to re-look at our habit of labelling anyone who talks very minimal technology as a "technical tester". The ability to Google has made it possible for anyone to google for a few terms, churn out a lot of gyan such as "SQL Injection testing", "Cross-site scripting", etc. and get the label of a "technical tester", whereas in reality, it takes much more than that and one who has the ability to understand the technology and domain, and then structure his test cases and "type of testing" accordingly would be 100% deserving of the label of a "true technical tester". Everyone else, who has ever tested a software product during their time on our planet, have every right to call themselves as the "Fake Technical Tester!!!". Happy Reading!!!!!

Friday, January 15, 2010

Is the Manual tester going to Die? Is he really important in today's testing world that bends towards automation testing?

A good question to ask.. - Gave birth to this thought while standing in today's lunch queue --- and in a way, this did end up as 1 kind of "food for thought". :)!!!

If I am going to look back at every testing article that I have read over the past few months, or every testing seminar that I have attended in the past few months - They have always offerred their thoughts on how to have better automation which would result in minimal rework.... Would this mean that the manual tester is going to be buried shortly? Does this mean that every test engineer should start developing automation skills for his survival?

My answers to these questions would be - NO & YES. ---> respectively speaking!!!...

Answering the 2nd question first, I really think that every test engineer should start developing automation skills without a second thought. That is the only way forward for him to survive in today's world. This would also help in career growth and in a way, serve as supplementary skills . This would give him the edge when compared with another tester, who does not have knowledge of automation.

Secondly, being in touch with automation tools would also keep the tester aware of what is happenning in today's technology world and make him more tech-savvy. But, having said that, it is not easy for any person to start developing automation skills overnight. This is something which can be done over a period of time - 6 months to a few years. He would need to chart out his journey in the arena of automation testing and plan on regular self-evaluation till the goal is reached.

Now on to the 1st question - will the manual tester die sometime? Is the new decade going to herald the death of the manual tester? Though the advancements in the area of automation testing tempt me to answer in the affirmative!!!. But, try as I might, common sense prevents me from saying YES. The manual tester is indispensible in any project. He is the one creature that nobody wants, but nobody can live without :).

It is impossible for 100% automation to be achieved. Ask any true software testing practitioner and he would subscribe to the theory that manual testing would account for at least for 40% of the defects found. - (this is if you have an effective tester in your team, who practices the art of software testing in a manner similar to how a doctor practises medicine, or a lawyer practices the art of law in today's world).

Most of automation testing world revolves around effective regression testing, and it's advantages or cost benefits are seen in the long run. When we receive the first build, it takes a manual tester to be able to find out most of the defects.

That brings me to the question with which this blog started - 1 differentiating point for the true tester and the fake tester - When you receive a new build and the tester finds a few defects, what would be his immedieate action?

Fake Tester - Would be more inclined to find a few defects , shoot off an email saying that the build has broken and that he cannot test anymore and be off to visit other websites while the dev team fix the defects!!!

True Tester - would be able to detect most of the high severity/priority defects, apart from emailing the defects he'd ask everyone to attend a conf. call to discuss the defects, do a root cause analysis of the defects and work on defect prevention in subsequent builds!!!

Having said that, the next question to me would be if I practise all that? Well, to be honest - I don't, and that's why I remain, the perfect specimen of the fake tester!!!!!

See you...

Wednesday, January 13, 2010

Hello World!!!

This is my 1st blog posting, and the best name that I could come up with was the fake tester. Before I write anything more, a huge thanks to the Fake IPL Player since the fake tester, is in many ways, hugely inspired by the Fake IPL Player.

First, Why a fake tester? Well, in the 1st place, everyone who knows anything related to computers thinks that he/she is a tester.

Want a career in computers? Become a tester - This is the 21st century buzzword. Why? Because software testing is perceived to be the easiest job in computers (directly contradicting relaity), since mostly the kind of testing that we do is only very minimal testing, and mostly whatever testing we practice would only be the tip of the ice-berg.

As I heard a person say, suffix every english word with the word "testing" and you would end up with some kind of testing - fast testing, speed testing, image testing, text testing, HTML testing, language testing, usability testing, UI testing , front-end tester, middle-tier tester, database tester, batch tester, screen resolution tester, screen tester, printer tester --- the list is endless..... while some of them do make perfect sense to practitioners, the others are attributes of the "true fake tester"!!!

that brings us to the question - Who is a "Real Tester"? And how do you find out a "fake tester"??? What is the job of a "real tester"? how do you differentiate a "Fake tester" and a "real tester"??? Well, thats what I intend finding out myself and that's the foremost reason of this blog... keep reading!!!

Well, to end this note, you might ask why not the "fake developer", but well, i ain't a developer ;)!!!