Dead cat in the well

“Once upon a time there was a village. The village relied upon a well for its water consumption. One day a cat fell and died in the well. The water was stinky and made the villagers sick. The villagers did not know how to take care of the issue.

During those days a Sage came by, passing through the village. The villagers sought his advice; they told him about their issue asked him for a solution. The sage told them to drain all of the water in the well and clean it up with water not from the well and drain that water too and wait for a few days till the new water oozes. This water will be safe to drink from then on. The villagers thanked him for the advice and wowed to follow it. The Sage went by his way and promised to return the following month.

A month went by.

The Sage returned to the village. He asked the villager how things were going on. The villagers told him their situation had not become better even after they had followed the Sage’s instructions. The Sage was surprised. He asked one of the villagers to bring him a glass of water from the well. In the water he found a cats hair. He immediately went to the well and looked into the waters. He found a dead cats body in it.

The villagers had indeed cleaned the water in the well, but never realized that the dead cat’s body needed to be removed. The sage gave them a solution suitable for the problem, but failed to understand the villager’s ways before he advised them.”

Moral of this story is “remove the dead cat’s body before cleaning up the well”, "Understand the villagers before advising them".


Remove the problem before making an improvement. It is not enough to paint over the walls when there is a hole in the wall. It is necessary to fix the hole and then may be paint it. It is necessary to fix the back-end of an application before making new and improved changes to the front end. You may take this example and make it your own, to fix a problem before making or adding improvements.

QA in most companies is like Sex Ed in most schools

The movie Mean Girls has a sex Ed class scene in it. The gym coach gets a bunch of teenagers into a room and explains about sex like – “at this age you will have urges to touch each other. If you do you will get pregnant and die. Don’t have sex. Guys promise you won’t do it!!” at the end of the class the coach brings out a bunch of contraceptives and offers to the students to make it look like they are serious about the "education".


Companies have QA teams. The QA team is trained for a release as such - “at this time you will have urges to do boundary value analysis, top down testing. If you do it and find bugs, we do not have resources or permission to fix them. Guys just do testing and nothing more.” At the end of the project they throw in automated testing for regression tell themselves that they are serious about testing.


This is (fortunately) not true with all companies. But if you are dealing with a situation similar, laugh out loud and do your best. You are not alone. Do your best for your product and help your developers do a better job. But don't give up.

Now, I cant say the same to the sex Ed teachers.

Tool is only as good as the user

As a SDET, I believe that the automation tools wrongly called testing tools, can do no testing. It is a tool that does what I tell it to do. I can tell it to go through all the pages and it will. I can tell it to pass a failed test and it will pass. I can tell it to fail the whole application and it will fail. Once again, it is a tool that does what I tell it to do.



Kind of like this story - 
Once upon a time there was a King who owned a device that worked like a lie detector. The device had a pointer that would point to the left when a person wearing it lied, and to the right when the person spoke the truth. The king was very happy that he found a device that will help him in judging people rightfully. The minister was concerned though. He did not believe the device was of such great use. He also feared, if would cause harm in certain cases.

One day the cops brought in a farmer who killed his landlord.  The cops put the device ("lie detector") around the farmer's throat and asked him if had committed the crime. The farmer replied "No". The device pointed to the right, which meant the farmer was telling the truth. The cops released the farmer. But the village folk complained again that they had witnessed the crime.

So, this case went to the King and the minister, where the farmer was asked the same question and the device pointed to the right upon the farmers answer. The King tried the device on himself and lied while wearing it and the device pointed to the left. This got the King confused. The minister stepped in and asked the farmer if had 'indeed killed the landlord?'. To which the farmer replied, "Yes". The device pointed to the right again.

The farmer killed someone, but he did not consider it a crime. So, that explains why the machine reacted the way it did. The machine did its job.


Tools will always be tools. Tools are only as good as the user. To find answers, we have to ask the right questions. To find bugs, we have to ask the right questions. Too many questions or less questions are not the key here. The right question in the right context matters. Even when using Google search or queering data base tables, testing an application, it is our responsibility to choose the words / questions / tests wisely.