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.

Quality Assistant

I am often asked about how I deal with my programmers on a day to day basis. The question means well, I am giving them bad news about their work. It is only natural for anyone to doubt - how this paid relationship works!?

There is this joke / story I heard a while ago that could explain the tension between a developer and the QA. Here the Wife is the Developer and the Husband is the QA.

Wife: (puts on a new pair of jeans) Does this make my butt look big?

Husband: (just stares, if he tells her the truth, she might get mad. If she does not her friends will tell her the truth and she will still get mad)

Wife: Honey, you can tell me. I won’t get mad.

Husband: You say that now….

Wife: I promise I won’t get mad. You can tell me anything. We should be able to tell each other anything.

Husband: OK, here it goes. I slept with your sister.


That is how I typically roll. I gain their trust and then give them a bunch of bugs I found. It is not my job to make sure every bug I logged is fixed and is accepted. It is  team decision to fix a bug now or to backlog it or reject it. It is not my decision or the developer's decision. (Although this is old school thinking from 1997).

Thanks to this notion, many organizations maintain their teams working against each other while working for the same goal (like “frenemies”). But there are teams where developers and their testers work together to build not just a product, but something great. In the later the A in QA means Assistance. Not assurance!

I mean what are we assuring? What can we assure? We are assistants. We are quality assistants to the developers. We assist them in doing a better job. We are not finding faults. Together we build a better product.

I have not met a developer who did not care about the quality of their work or their

product. So, they care. They don’t just code and sit back for the QA to find issues and work on putting them down. They do their part of testing to make sure their code works. It is my job to make sure the product as a whole makes sense and it sensible (Yeah , yeah, bug free, what ever that means).

I prefer to make my application better by continuously exploring it, learning about it and respecting it. I dont believe in breaking it or trying to break it. (Again 1997??)

Lots of Work

“Working so hard”

“There is a lot of work to do”

“Such a big application”

“So many bugs”

 "Too much work load"

 "Not enough time"

What should it really mean to the person hearing it? – Nothing.

I have seen members take loads of work and not bat an eye and do it with ease.

I have also seen members take little work and make it look big and stress out and stress others out.

I have also seen organizations that plan and work smart.

I have seen organizations that plan to work really, really hard.

I am not here to explain the right way of doing things. Whatever floats your boat!! Lol

But, when people talk about a lot of work, it reminds me of the Woody Allen movie – Annie Hall

There is a scene in the movie with a psychiatrist. The conversation goes like this -

Alvy's psychiatrist: How often do you sleep together?
Annie's psychiatrist: Do you have sex often?
Alvy Singer: Hardly ever. Maybe three times a week.
Annie Hall: Constantly! I'd say three times a week. 

The frequency is three times a week for both, but the perception of excessive or insufficient varies between people and their wants and capacity. Especially how much, they can get away with.

Testing Prometheus (the movie)

Why was this movie not good? It was not bad!!

1. The actors were beautiful with all star cast 
2. The acting was top notch
3. The direction was also brilliant
4. The CGI and stuff was excellent
5. The cinematography was breathtaking

Most of the geographical aspects of an alien planet were pretty nicely captured. But the movie lacked something. Something was missing. It even irritated quite a number of audiences. It gave the audience a visual treat but stole the original experience they have craved for decades. The core of movie which is the story did not know what it wanted to give to the audience. Resulting in travelling a group of brilliant scientists without letting them know their mission, a pretty girl who works out like crazy but cannot stop running straight, a zombie, an alien snake, a beautiful android who knows too much or just curious, a dead old billionaire who is not really dead, a female scientist (I don’t even want to touch that). And the alien creator guy rips of Michael Fassbender's face Who does that. I don't care what he created and wanted to destroy, he is dead to me!!

Testing Software is kind of like that. Brilliant business analysts that come up with a vision for something better, Artistic UI designers who go for a visual treat, top notch geek developers that develop a product or app, and the QA that test the heck out of every component along with integration testing.

All the items on the check list are checked off. Every item passes with flying colors. And the product is released to the world to deal with. With all its beautifulness and latest and greatest technology and perfection..

1. If the product does not make sense to the user, the user feels stupid.
2. If the product does not give a good user experience, the user feels won’t come back.
3. If the product takes too long to understand, the user is robbed of their time.
4. If the product does not deliver what is said, the user is feels cheated.

Product that meets the promises made to the customer along with a good user experience will last and thrive. Prometheus made the money it deserved same like the iPhone.

How well do you know your QA?

QA efforts valued based on the bugs that make it to production.

Once upon a time in an Asian village, there lived 4 brothers. All the four brothers were doctors.

The eldest brother treated many patients for years. 

1. He charged reasonably for the years of treatment.
2. Most of them advanced to terminally ill condition. 
3. Many of them died. 
4. He talked a lot about all the reasons that lead to the patient's death and how his treatments to save the patient became ineffective due to reasons not in his control. 
5. He was famous all over the village and a little in the surrounding villages too. He was very important to them. 
6. He did not get a bad rep either. People thought he did his best.

The second brother treated patients with care too for months.

1. He charged an arm and a leg as his fees.
2. A few of his patients became chronically ill even after months of treatment. 
3. Most of his patients survived and recovered. 
4. Few of his patients became terminally ill.
5. He explained about all the reasons for why he had to charge so much for the treatment. He also had reasons for why the patient could not be saved for reasons not in his control
6. He was famous in his village. He was important to them.

The third brother treated patients for weeks.

1. All of his patients survived and recovered. 
2. He charged reasonably.
3. He was known by a few people in the village. He was considered to be okay. 
4. People did not prefer to pay enough for his services.

The fourth brother never treated any patients actively.

1. He studied all the patients that came to his brothers.
2. He invested all his time on preventing diseases than curing them. 
3. He was more interested in prevention than cure.
4. He was not known by anyone in the village. He was never paid enough even to cover for his research. 
5. He was not valued as much. And sometimes he was considered pesky and hindering to the specific lifestyle the villagers were accustomed to.

QA people are valued the same way too.

A company values its QA team and invests in it when a lot of bugs make it to production. And seriouslyunder values the QA team that makes sure issues are nipped in the bud. This is when the upper management decides that their code is so clean and bug free, they may not need the QA team who are always asking for more time or resources and sometimes becoming the gate keepers for releases.

Oh! The irony.

Moron Vs. Oxymoron

I had the luxury of working with insanely smart people.
I had the misery of working with mind numbingly inane people too.
I had the luxury of working for morons and reporting to oxymoron.
The moron are okay, they don't know any better. They can be educated.
The oxymoron's they do know better. They purposefully want you to swim against the currents just to prove a point to nobody, not even themselves. They cannot be reasoned with.
I would totally run from these!! And I have.

I am a Bitch

The Circle of Office - 
I am a Bitch (not in general)
I am my boss' bitch.
My boss is their manager's bitch.
The manager is the vice president's bitch.
The VP is the CEO's bitch.
The CEO is the bitch to all the stake holders.
Instead of bitching about this situation, I try to be the best bitch I possibly can be (excuse the expression).

When it comes to working in an office, we are confined to cubicles physically and to the manager’s invisible boundaries. Learn to live and learn to grow.
If you signed up to swim in a pond, do not complain that it is not as challenging as swimming in an ocean. If you signed up to swim in the ocean, do not complain that it is not as predictable as a pond.
Do the best you can. Learn to use the currents. Do not work against them.
If you do, you will fail and a new swimmer can replace you.
One should be replaced for sucking at ones job, not for trying to make a work place better.

Update - Well, this is what I thought, till I worked at Amazon and Porch. When I worked with a great boss, I was myself and it felt great. I was happy. 
No, I don't want to be a bitch in any sense. Not anymore.