Tuesday, October 15, 2013

Story- Identifying mystery bug

QA life experience ... 

Software testing, yeah I know, such a painful tedious job. Testing the some/same thing again and again. I was given a task once to identify the mystery bug that was driving the arm of a device in auto rotating mode. Obviously I cannot write anything detailed about it. It was one of my interesting bug identifying incidents that I’ll remember for long time. This issue was given to me with a high hope that I’ll be able to find the issue and I was able to find it (without knowing any details of the code/ logic).


In simple words of mine, when any function does not work as it should work or d
Lets start describing the problem first. Customer Service department was receiving calls about the issue that was driving the arm of a device. Anyway, it was happening out there in the field randomly with different heavy weight metal attachments on the arm. It was very confusing, at least what was recorded in text. There were several attachments that are possible to attach on the arm. Each attachment will then set to a certain Range of Motion (ROM). ROM can describe as a Circular path. It can be a 360 degree of rotation. Once the ROM is set, then user will have to verify the ROM by moving the arm within the specified ROM. After that when the test starts from a starting point of the ROM, the attachment/arm will be moving within the ROM specified. It was supposed to move when someone move the arm. In other words, when some force applied on the arm, it starts to move. In short this was the way of operation for this device.

When I was told to find the issue, obviously I looked at the text of the complaint from the customers. There were few of them. Those were recorded in different ways. My first attempt was to try as per description. To understand more about the customer complain, I actually talked with the customer service department. They gave me few details that I felt was important but not recorded in the report.  (Always dig for more information. You never know what/when/ who will give you the CLUE).

Next few days, I tried to perform test according to the description/input from customer/service dept. tried to duplicate the issue. Could not figure it out what is going on. When something like this happens, I usually take a break from testing and go back to the drawing board of testing plan. This helps me to calm down and rethink about testing approaches. I felt that I did not have full grip of the issue. I didn’t understand how the system should work for each attachment. I went to talk with some people who knew more about these products. They were explaining in more details how things should work.

Now, once I know more of the issue and more detailed information about the product, I started to layout out my testing approach differently. When the test starts, it was supposed to start from the starting position- which is either of the ROM end limits. This was most important part I missed during my previous tries, which made me a little bit frustrated as well. I was following what either it was reported or told by the knowledgeable person of the product. As a tester, this is why I always try to think out of the box, out of the conventional method. Anyway, when I tested the thing from either end, it was okay. When I performed it from the Center of the ROM limits, it even worked!!! I was going to be crazy. Then I thought about applying force on it at the time of start and then from the center position of the ROM. Yahoooo! I got it, I did it. I was able to duplicate the issue where it starts moving the arm automatically.

It did it, when arm was in the center of the ROM and some force applied to the arm to pass through the middle point. Once it misses the middle point of the ROM, it keeps trying to find the middle point and moves on for indefinite time.

So, Why? Why I applied force? Just think it logically, or I should say practically. As I described earlier, attachments are attached to the arm and then during testing it moves. When the attachments are attached, it was supposed to stand still. Not to move one inch. Then the command sent to the controller to release the arm and arm moves. Attachments have their own weight. Let’s say I positioned the arm right before the center of the ROM. Then when I put those metal attachments, it moved just a little to pass the center point of the ROM and then it continuously move on. Some logic was used to identify the middle of the ROM after the arm started to move for some reason.

This was a great relief for the company. We were able to find the issue and fix it. The fix took near about 30 mins to an hour max. Without knowing anything about the code logic, or any specific details, by thinking about the issue logically, I was able to find it out.

I have learned from this that it's pretty important to have in depth knowledge, good grip of the product and its practical use. 

Have a wonderful day. 

No comments:

Communication - it's very important in recruiting people

One of the common part of our professional life is we get mails from recruiters time to time regardless whether you are looking for job o...