Software QA FYI - SQAFYI

Logging Bugs on Mobile Applications Testing

By: Jonathan Kohl

Sometimes we spot a problem, stop and write down the steps it took to reproduce it, and then move on with a task. A few minutes later when we decide to log the issue formally, we can’t repeat it. In other cases, we repeat the issue once ourselves, document the steps to reproduce, only to have the bug report sent back to us because the programmer can’t repeat it. We’ll talk about how to cope with intermittent bugs later in this chapter, but to reduce the waste in time and energy incurred by logging something others can’t repeat, I use Jerry Weinberg’s “Rule of 3.” When I am filling in a bug report, I make sure I can repeat the bug three times before I start recording it. If I can’t repeat it three times in a row, I need to spend more time researching and investigating before logging a report for the programmers. Some are quite easily repeatable, so I move on and start gathering information and logging the bug. Others may occur once out of three attempts. I will then try to repeat it more times, and I may only be able to repeat it five times out of ten, or thirteen times out of twenty attempts. If that’s the case, I add the word “Intermittent” to the bug title and include those metrics. That just means that the programmer will have to try to repeat it a few times rather than once to be able to repeat the conditions and start fixing the bug.

Clear Title and Description
I describe the problem in the simplest, clearest terms that I possibly can. This is like the headline of a news story, it needs to be compelling to draw in the reader. Examples include:
* “Poor performance during application launch on iPhone 3GS”
* “Application crashes when submitting purchase form with a weak wifi signal”
* “Incorrect login error message is obscured in French due to special characters”


I spend time on my titles to make sure they are clear and free of typos. It sounds easier than it is, I will often go through several ideas per bug until I get it right. I will frequently ask a colleague if my bug title looks ok or not if I have any doubts. I also have a brief description, usually based around a task or fulfilling a goal to put context around the bug. That helps the programmers figure out why they should fix the bug, and what sort of priority it should have. Here is an example: “While walking between wifi connections, I tried to submit a purchase, but the app crashed. This seems to happen when the wifi signal is weak.”

Full article...


Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/

Logging Bugs on Mobile Applications Testing