The Hot Air Balloon

Ever work in a company where the upper non-technical management made all the decisions, and the IT team had no team say in making the decisions. Why does that happen?

A man saw a hot air balloon and starts to float. He enjoys the ride. After a while he looks down and realizes
that he does not know how to get down to the ground and also that he is not in a safe place either. He hurriedly looks for civilization and finds a woman strolling.

He yells to get her attention and he gets it. He asks her if she can get him down to the ground? The woman thinks for a little bit scanning the premise, she then replies - "Your balloon is 40 feet from the ground. 20 miles from the city. The air balloon cannot last for more than 1 more hour. ...." and she went on.

The man in the air balloon interrupts her and asks her "You are in IT. Aren't you?"
The woman replies "Yes, Yes I am. How did you know?"
The man says "Well! what you explained to me is probably accurate, but it is not helping me get down!!!"
The woman thinks for a little bit, and asks "You are in upper management. Aren't you?"
The man replies "Yes, Yes I am. How did you know?"
The woman answers "You get your self in a hot air balloon without much prior knowledge about it and just expect others to fix your issues magically!!!"

Now, is this an ideal situation?
Shouldn't the people making the software make the decisions about its dates and features and all?
Well, that would seem like the ideal way to do things, but there is a catch.

Parkinson's first law - Work expands to fill the time allocated for completion. (Developers write enormous code that doesn't add value to the quality of the application.)

Parkinson's second law - Expenditure rises to meet the income. (Employees trying to create work to keep each other occupied rather than really work for the organization.)

Parkinson's third law - Expansion means complexity. (Once the budget is increased, more changes and resources are added to a project irrespective of necessity.)

Parkinson's fourth law - The number of people in any working group tends to increase regardless of the amount of work to be done. (Family junk expands to fill the attic.)

So, is the hot air balloon good for the projects and good for our work prioritization?

To Process or not to Process

A long time ago, there was a land lord who started the tradition of throwing a huge party for all of his town folk in his huge backyard once a year. Right before the party began, the land lord would get his men to catch his pet Cat and put her under a wicker basket and then put a brick on top of the basket. Right after this event, the party would begin.

The landlord passed away and his eldest son took over the family house and the traditions. The eldest son did not have a pet cat. But every year at the time of the party he would instruct his men to get a cat. He would then put the cat under the wicker basket and then put a brick on top of the basket.

This tradition was as important to this landlord’s family as having a real turkey or a fake tofurkey on Thanksgiving to most of us Americans. Nobody had any issues with this process, so they went on carrying out their practices.

Now, let’s try and understand about why the landlord originally used to lock his cat right before the party began?

1. The landlord really loved his pet and did not like to restrict her freedom. 
2.  The landlord liked to devote his time to entertaining his guests at the party.
3.  The landlord was afraid of his cat hurting other kids or even worse someone stomping his cat by mistake.

So, in order to take care of all the three issues, the land lord used to lock his cat up for her own safety and convenience of the guests. He used a wicker basket because he had them in abundance at his house. He used to use the red brick to weigh down the wicker basket restricting the cat to tip over it and run loose.

His son had observed his actions and followed the actions, but did not try to understand the purpose behind the actions.

What is a process?

Process is the practice of executing related tasks in a certain way to accomplish a goal.

1.       This practice could be executing tasks sequentially synchronized.

2.       This practice could be cataloging tasks in a certain way for easy identification.

3.       This practice could be to identify certain annoyances and take care of them.

4.       This practice could be to have gate keepers at certain locations.

5.       Etc.

Example of a process –

Waterfall  

Agile 

Scrum

  Etc.

Q. When to follow and not follow a process?

Many companies and projects like to implement the text book version of process without first understanding if the process will work or break with their core. And this is not necessarily the best way to implement anything.

1. Process for the sake of process does not add any value to the team and the company.
2.  Ever revised process will help the team to be efficient.
3.  Understanding of why to do certain tasks in certain way makes for a better process.

Process is good. Following a suitable process is as effective as epilating regularly (it is less painful with fewer surprises and leaves few chances for public embarrassment). Keep revising your processes and make sure it works for you. 

Digital Fast

 

A very good friend of mine recently used this word in the sentence “I was on a digital fast, so I could not reply back to your email immediately”. My friend was on a digital fast by staying away from all social media like Facebook, LinkedIn, Twitter, Google+ and even emails (in certain cases).

We are over stuffing ourselves with all this social media, texting and constant information update. It would be nice to take a break from all of that and go on a Digital Fast to clear our schedules and minds. It would be like tasting food and appreciating it after a food fast.

It would be kind of impossible to shut down everything we use on a daily basis. But we can cut down on one digital media one day a week.

(I would love to blabber about the pros and cons but you know yourself with your media better)

Testing without Requirement

I have tested without requirements loads of times. I had no other choice!! I worked for companies whose software applications were older than me. So, how did I go about testing them?

I looked at the login page (the gate way to the old world). I poked around it. I found fields for username and password and a button login. I clicked on the button. Nothing happened. I mean not even an error message. That was my first bug. The username and password fields allowed me to enter more than one thousand alpha numeric characters. Few more bugs.

At this point, I was warned by my experienced colleagues that we do not need to test in those ways because the user

would at most type in 20 characters only. I thought, may be my experienced colleague has a point to it. Maybe I should not spend time on doing basic software testing. I should do real functional testing; I should learn to use the application just like everybody else. Thinking so, I decided to end my test and hit on the button Login button (to finish what I started). The application suddenly closed and instantly took down all the users that were using it too. I crashed the backend. My first reaction was “I am so fired for this”. My next reaction was “Could I log this bug without getting into trouble because it looks kind of critical”.

I found more bugs without referring to a requirement. When I use the requirement, I can certainly get to the places I might not know about. But if I limit myself to testing as per the requirement, I will certainly miss out on exploring the application for what it is and to figure out how better it could further be.

Test the pencil

(Not to be mistaken for the pencil test)
 If the requirement for a pencil was to write 10 pages, and during testing the pencil ended up writing 12 pages.
What should the testers do? Pass it or fail?
Should the testers PASS the pencil test because the result was better than expected?
Should the testers FAIL the pencil test because the result was not per spec?
May the testers ask for more specs regarding the weight and thickness of the overall pencil?
May the testers ask for more specs regarding the weight and thickness of the lead core?
Should the testers re-test the darkness of the writing?
Should the testers use other kinds of paper for executing re-testing?
What would you do as a tester?
Why should you do anything else besides testing and giving a pass or fail?



Possible defects – 

1. Longer pencil than mentioned in spec
2. Thinner lead core than mentioned in spec;

Possible concerns – 

1. More money is being spent on the pencil
2. Less return of investment may be the result.

A few opinions I collected over the years - 

1. Need more clarification and information
2. It is a FAIL because the company could be losing its return on investment.
3. It is a PASS because more the merrier
4. When the requirement was to test till 10 pages, the tester should have stopped testing at 10 pages. The extra testing is exhaustive testing. We should limit our tests to the resources we are provided only.

What would you suggest and do, if you faced such a situation?

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.

If testing was like sex

No wonder most Software out there is f...ed up and violated!!

According to Freud - the unconscious mind and the primary motivation for all things in life is sex. So, I am comparing software testing  behavior to making love during my leisure (bored out of mind) time. One more reason for doing this - both these subjects are kind of taboo even in the most open minded culture.

A first time virgin tester does their best, completes the job as their instincts tell them and from all the
documentation (videos) they had learnt from. But they know there is more to it than just completing the task.

In a stress free environment, the tester is enthusiastic and wants to give their best because the application deserves the best (in order to improve the product, make it bug free). So, they get the book that contains all the various techniques for completing the task. They learn and apply all that they learnt. During the process they understand there is no way in hell they can go through some techniques, due to lack of time or lack of more knowledge or it just does not make sense.

In a stressful environment, the tester does not dare to attempt more than what is expected. The job is complete and that is all that matters. They do not have the luxury of knowing the application more. Besides no on ever got fired for missing a bug.

In a perfect environment, the tester does not just jump in to finish the task. They get to know the application. The more they understand the application, the better they can plan their tests. They may be the one or they may not be the one. They wont know more till they explore.

A knowledgeable tester will realize it is the best thing to step down if they are not equipped to test the product.
An intelligent tester will train themselves to gain the knowledge necessary to test the product.
An average tester will just hang in there and look busy while doing their best.

A tester that takes the time to learn about the application and takes the time to explore it can come up with the best possible tests suitable for the particular application. Every application is unique with certain similarities. They may all look the same but they come from different places. Their needs are different. Their environments are different. They are made differently. They are made with sugar and spice and everything nice. (lol)

Do not assume your application is your female dog. Know your application accept it with all its flaws and respect it. Then custom design your tests. Never stop exploring. There is no stopping you now.