Its my baby, I don't want to break it

The old school philosophy of testing is "Break the software". I used to think this way and be driven this way. Then I realized something, when my focus is on breaking something, my approach is attack mode.....

If I want to break a glass vase, I throw it down and it breaks.

If I want to break my software, I find vulnerable spots and take a jab at it.

Then what?

I report, "hey, its broken" and probably feel proud that "Hey, I broke it!!"

Then what?

I don't know. 

I am not sure if this approach every worked for me.

I usually fall in love with most products I work on. They are my babies. I want the best for them. I want them to evolve and improve. I want them to co-exist with their sibling applications. I want them to have a unique name in the software industries. I want to give them the best opportunities I can provide with my team.

It takes a village

It take a village to raise a kid.

It takes a team to create a product.

Know the history

Know where the kids come from. Their background, family history, family health history and such.

Know where the idea for the application come from. The requirements and the needs that lead to creating the application.

Understand what they want

We want to give the best of the best to our kids. But that wont make them happy. Understanding what they want and trying to give them as much of what they want will make us happy.

We want to create the best possible application. But the application may not need the extra bells and whistles. It just needs that extra umph. Try to give what it needs with what we got.

Protect them from threats

Kids should be educated about pedaphiles and manipulators so that they can protect themselves when we are not around. Because, the bastards always make sure the kids are alone to take advantage of them. Provide them with whistle or phone or a process to attract attention when in trouble.

Software should be prepared to deal with hackers and hijackers so that they it can protect itself anywhere in the world. Provide them with Captchas or trace of analytics to understand what happened when.

Extra care when sick

We have to give extra attention to the kids when they are sick. Not hate them for being sick.

We have to give extra attention to the application when they are vulnerable. Not walk away and abandon them.

Rules have to be followed

Kids may not want to follow rules sometimes. But they should not be given an opportunity certain times. They have to follow the rules as part of the society

Application functionality may become dull or not enough adventurous some times. That is okay. It is for the application's own good. It is to follow some rules a it is part of the society.

They will leave the nest

Don't try to hold on to the application out of fear of being jobless. When it is time, it is time for the application to go through new process and into new departments and have a life of their own.

Enjoy them

Enjoy being with the kids. Explore the world with them. Talk about anything with them and see what they think. If they need to understand certain things more than the other, explain it to them.

Enjoy working on the application. Explore the software world with it. Input anything and observe what comes out. If the software needs to be tested in other ways using other tools, definitely do it.

Watch them grow and evolve

Watch your kids grow and evolve into something wonderful

Watch the application grow and evolved into what it is meant to be.

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.