Tuesday, December 5, 2017

Take every bug report seriously (Part 2)

Introduction


Many engineers value rationality above reality. Even if they see something is happening in front of their eyes, they will want to discard it as a "one-off" case if they can't find a reason behind this. 

I have seen this during several instances. Many a times, bugs filed by QA Engineers are discarded by Dev Engineers as "Not Reproducible" if they cannot find a reason why the bug would have happened in the first place; or if they cannot reproduce it on their systems ("It works on my machine!").

In this series of blog posts, I will post many stories that helps us (the engineers) understand the importance of treating every defect seriously.

Story #1


Story #2

Eight years ago I was working as an escalation tech for a high end computer manufacturer that is no longer in business. They specialized in very expensive home rigs. One of my techs received a call from a user on the east coast complaining that their computer would reboot for no good reason every evening around the same time, give or take a couple hours. The tech checked all the obvious settings (BIOS, Power Management, etc.) but could find nothing that was telling the computer to reboot at any particular time. It was running <shudder> Win95, not NT so there were no OS timeouts available. 

They then started working the hardware angle -> remove all add-ons and see if it still has the same problem. Disconnected the printer, scanner and joystick and ended the call. A couple hours later user calls back saying the computer had just rebooted on its own again. The new tech followed up with the first tech to see what else needed doing and they ended up escalating to the supervisor for an RMA of the power supply or mobo. Sup decided to RMA both because he could not prove which one was bad.

Customer got new parts, installed them himself and was up and running for the entire weekend. Monday rolls around and he calls back in the late evening (7 or 8PM) with the same problem. This call got escalated straight to the sup who decided we needed to RMA the entire tower and have the repair team take it apart. A week later customer gets his system back with all new components inside. The only thing that was not replaced was the case (serial number). They even replaced the front bezel of the case in case it was a malfunctioning reset switch.

That night he calls in again WITH THE SAME PROBLEM. At this point, my sup decides there is no way the problem exists within the confines of that computer case so he hands it to me to try and figure out (he didn't like me very much). While I'm talking to the customer (about 50 minutes into the call) I hear a noise in the background. He immediately lets me know that the computer has just rebooted. The noise that I heard did not sound anything like what you would expect to hear from a computer that just came out of the box, so I asked him what was the noise that I had just heard. He informs me that his wife had just come home from work and was "finishing her business in the bathroom".

I pondered this new bit of information for a while. I asked if she works a regular 8-5 type job and always comes home at the same time, every weeknight. His response was that sometimes she works late and then gets to come home early the next day, but that it never varies by a couple hours.

After the computer was back up in Windows I asked him to go flush the toilet and then come back and check the computer. He did and sure enough, it was in the process of restarting. I then asked him to check for any wires leading into the tank of the toilet. He informs me that there is no tank on his toilet. He "only buys the best" so instead of having a tank, he has a water pump that pumps water into the toilet from a water reservoir in the basement that is kept at room temp (also supplies water for the bathroom sink and indoor watering system for all their potted plants - more money than he knows what to do with, obviously).

The water pump just happened to be on the same circuit as the outlet that his computer was plugged into. Despite the use of a surge protector, the water pump kicking on put enough of a drain on the circuit to cause the computer's power supply to momentarily die (this was 8 years ago, before digital power supplies), but was not a surge so the surge protector never tripped. I had him move his computer desk to another wall in the same room and plug into one of it's outlets instead. This moved him to a different circuit and solved the problem.




[NOTE: This popular story has been taken from Internet. I do not know the very original author, so have not attributed to him/her.]

Take every bug report seriously (Part 1)


Introduction


Many engineers value rationality above reality. Even if they see something is happening in front of their eyes, they will want to discard it as a "one-off" case if they can't find a reason behind this. 

I have seen this during several instances. Many a times, bugs filed by QA Engineers are discarded by Dev Engineers as "Not Reproducible" if they cannot find a reason why the bug would have happened in the first place; or if they cannot reproduce it on their systems ("It works on my machine!").

In this series of blog posts, I will post many stories that helps us (the engineers) understand the importance of treating every defect seriously.

Story#1


A complaint was received by the Pontiac Division of General Motors: 
"This is the second time I have written you, and I don't blame you for not answering me, because I kind of sounded crazy, but it is a fact that we have a tradition in our family of ice cream for dessert after dinner each night. But the kind of ice cream varies so, every night, after we've eaten, the whole family votes on which kind of ice cream we should have and I drive down to the store to get it. It's also a fact that I recently purchased a new Pontiac and since then my trips to the store have created a problem. You see, every time I buy vanilla ice cream, when I start back from the store my car won't start. If I get any other kind of ice cream, the car starts just fine. I want you to know I'm serious about this question, no matter how silly it sounds: 'What is there about a Pontiac that makes it not start when I get vanilla ice cream, and easy to start whenever I get any other kind?'"

The Pontiac President was understandably skeptical about the letter, but sent an engineer to check it out anyway. The latter was surprised to be greeted by a successful, obviously well-educated man in a fine neighborhood. He had arranged to meet the man just after dinner time, so the two hopped into the car and drove to the ice cream store. It was vanilla ice cream that night and, sure enough, after they came back to the car, it wouldn't start.

The engineer returned for three more nights. The first night, the man got chocolate. The car started. The second night, he got strawberry. The car started. The third night he ordered vanilla. The car failed to start.

Now the engineer, being a logical man, refused to believe that this man's car was allergic to vanilla ice cream. He arranged, therefore, to continue his visits for as long as it took to solve the problem. And toward this end he began to take notes: he jotted down all sorts of data, time of day, type of gas used, time to drive back and forth, etc.

In a short time, he had a clue: the man took less time to buy vanilla than any other flavor. Why? The answer was in the layout of the store. Vanilla, being the most popular flavor, was in a separate case at the front of the store for quick pickup. All the other flavors were kept in the back of the store at a different counter where it took considerably longer to find the flavor and get checked out.

Now the question for the engineer was why the car wouldn't start when it took less time. Once time--not the vanilla ice cream--became the problem the engineer quickly came up with the answer: vapor lock. It was happening every night, but the extra time taken to get the other flavors allowed the engine to cool down sufficiently to start. When the man got vanilla, the engine was still too hot for the vapor lock to dissipate.


[NOTE: This popular story has been taken from Internet. I do not know the very original author, so have not attributed to him/her.]


Friday, June 8, 2007

Daily Diaries using "notepad"

I just tried it on my Windows machine, and it works!!!!

* Create a new file, say MyDiary.txt and let the first line contain the following string:
.LOG
* Close the file, saving it when asked for.
* Open this file using "notepad", you would see an entry with the current date and time. Write your diary and close it (of course, save it!)
* Open this file again, you would see the prev contents, and another new line with the current date and time.

Looks like a sweet and simple way for creating diaries.

Note: I also tried it with TextPad (v 4.7.3) and WordPad -- this works with TextPad, and not with WordPad.

enjoy!

Wednesday, May 30, 2007

About me

I have had this blogger account for quite some time, but never really got down to writing something in this. This may seem unusual for people who know me well ---- they know that I have a penchant for writing --- whether it be for magazines or for newspapers.

My first post in this account is going be a brief history of me. I will try to keep it as brief as possible:

I am Anand Sinha. Anand means Bliss, Happiness. [Ignorance is not Bliss] and Sinha is my family name.

I was born at Begusarai in Bihar (INDIA) on the 24th of November. My education began in a school named 'Progressive English School' in Begusarai.

I joined a hostel when I was just 9 years old. The hostels include:

* St Xavier's School, Sahibganj - 1983 through 1989
* Modern School, Barakhamba Road, New Delhi - 1989 through 1991
* St Stephen's College, University of Delhi, Delhi - 1991 through 1994 - B Sc.(Hons) in Mathematics
* Department of Computer Science, University of Pune - 1994 through 1997 - Masters in Computer Applications (MCA)

I joined Novell Software Dev Ltd (Bangalore) as a campus recruit when I was doing my MCA at University of Pune. Before joining the company, my gang of friends decided that we would stick in our 1st company for at least 5 years. In August this year, I am going to complete 10 years in Novell. It has been a great place for working and learning. I am still working for Novell...

On June 22nd, 2004, I got married to Richa Saurabh who hails from Patna (Bihar, INDIA). On September 13th, 2005, we were blessed with a baby boy, whom we named Chitraansh.

In 2005, I joined an MBA course (PGSEM) at Indian Institute of Management, Bangalore (IIM B) for my management studies along with the work.

Last month (23rd April, 2007), I moved into my own apartment in Bangalore - Purva Panorama ! Lot of work is still going in the apartment, which eats away the time that remains after working the entire day and Novell; and weekends at IIM.

Let us hope that I find time and energy to update the blogs at regular intervals.