It’s the little things Martin Jansson
As a tester you find lots of things that bugs you when exploring a system. In some cases these issues only nudge you slightly at first, but after passing over the same issue many times it really starts to drive you crazy. This, at first small issue, has now become something that affect you more than you initially thought.
An example:
A feature in my Samsung mobile is annoying. I have a bluetooth headset. When I switch this on and enter the bluetooth settings on the mobile I cannot find the device the first time I enter or scan for it. I must go back then re-enter to find it. I do this every time I connect the bluetooth, which is a few times every day. After having the phone for a month it starts to irritate you. It might be my headset that is buggy or might be the way bluetooth is done on the Samsung. Either way, my experience of my Samsung is damaged and especially this issue is something that nudges me continuously.
When we are testing and report an issue like this, it is usually set to minor severity and as times goes by we want it to be of higher severity. As I see it, it is your obligation to update the bug with your new feelings and reactions. Because our first reaction to something might not be what we feel about the same subject further on. Our initial estimation on severity and priority of bugs should therefore be continuously revised and rethought, if time permits that is.
For many testers you will start to ignore the issue and not see it anymore, thus becoming biased [1]. There is also a big chance that you will suffer from the effect of the Broken Window Theory [2] by accepting similar issues to pass by. It is my belief that we very often give a faulty set of priority and severity when we do not know the system well, but the more we learn and understand the better chance we have to know how important and serious the bugs are.
References
[1] http://www.workroom-productions.com/papers/The%20Irrational%20Tester%20v1-06.pdf
[2] http://www.theatlantic.com/magazine/archive/1982/03/broken-windows/4465/
Funnily enough all the things that bother me as daily bugs relate to my phone too.
I always tell my team that they are at their best as application testers early in the project as they are more likely to notice the usability issues early in the project as they step (work)around them later on.
With our phones we rarely have that option so notice the issues much more clearly.
Good example!
The whole consists of details, and if it is cumbersome often, it is an important quality problem.
The quality of details are decided by the whole, and for phones it is especially important that they are fast to interact with, since you do it often. (I still think the old phones had unbeatable usability; pick it up and start talking.)
Testers are the best catchers for issues like this; since we experience a lot of the details, often.
Besides making a case for individual bugs, we could summarize findings and communicate stuff like “if we really want to make a smooth product, we should address bugs 6, 13, 19 and 28, because they will annoy users, often.
In your particular example, my guess is that either the bug wasn’t found, or it was outside a functional tester’s responsibility…