Tuesday, October 16, 2012

Bug Investigation - Never Give up...till you tried enough

          After many days, I got my office laptop home to verify some bugs assigned to me. Some are disciplined enough to focus on only the bugs first. I belong to the category of people who are inquisitive enough to probe areas closer to the bug, find new bugs and log them. On verification of one such bug, I noticed something strange.

The Bug Appears
There was a popup and there was a browse button to choose a file to upload. I clicked on the Browse button but nothing seemed to happen. I clicked again and the file picker window opened. I was pretty confident that I had clicked on the Browse button the first time too.
Confidence doesn't help you unless you have proof especially in the case of bugs.
And as I have got into the habit of recording ( http://bit.ly/SYpIlG ) my testing sessions, this too was recorded. The next step was to follow the advice given in BBST Bug Advocacy Course (Remember RIMGEA? ) on encountering a bug. I tried to identify the critical condition, recorded a shorter video and  logged the bug.

The next day morning, the programmer pinged me on Skype asking if I could still replicate the issue?
I could not :( 
Immediately, I noticed few differences.

  • Firefox browser was updated [The issue I replicated was on a lower version]
  • This build was deployed early morning whereas I had logged the issue on a previous build.
  • The programmer was testing on a different account. 
The advantage of recording the sessions is that I don't need to remember every detail of the bug. The important, obvious details are recorded and my mind is free to remember some other information.
I replayed the video. The programmer was also watching it. I could not replicate the bug.

It is easy to assume that the different factors has a major effect and close the bug as non-reproducible.

The bug is Nailed
I did not give up. Points from James' blog post were crossing my mind. I observed the video more keenly. Immediately, a thought process started. The video showed 12:27 AM - which means - I tested at home - meaning - a different network - TATA PHOTON data card. Bingo! Is the bug caused by difference in network?

I always carry my data card with me - what if the office network is down - I don't want to depend on one factor alone. I immediately disconnected from the office network and connected the data card to the laptop.

The bug was reproduced. I was happy that a combination of factors helped me replicate the bug.

Proof (Recording), Resources (Data card), Observation (Time & inference about the network speed).
I wanted to share this story - its like the war story where you successfully defeated your enemy.

I would love to hear about your war-stories.
PS: Did you know how I searched for the blog post by James. Refer the image below. I applied something which I learnt in the Power Searching With Google course. What is the use if one doesn't learn and what is the use of learning if its not applied? :)

Power Searching With Google course lesson

2 comments:

Sanjeev said...

nice one!!!!

QA Tester said...

Good One!!! hence proved that the tester has to be always attentive to as many factors as possible with your example. Smart work!!