Last week I came across this article about Samsung fixing an SMS bug in their software. For the most part, it’s the typical “we found a bug and we’re fixing it” story that are just a bit too common in the news these days – but I was struck by this line:
Another annoying bug is related to the fact that the device cannot maintain phone calls longer than 3 minutes without rebooting.
To me, that’s a much more interesting (and critical) bug than an SMS issue. Yes – I do realize that a lot of people use their phone far more for SMS than making a phone call, but come on…
But I’ve also been wondering lately about tester judgment (there’s probably a better word for this, but for today, it will do). How do testers determine if a bug is a bug anyone would care about vs. a bug that directly impacts quality (or the customers perception of quality)? (or something in between?) Of course, testers should report anything that may annoy a user, but learning to differentiate between an “it could be better” bug and a “oh-my-gosh-fix-this” bug is a skill that some testers seem to learn slowly.
I once saw someone post a bug on their blog and ask readers to identify it. It was interesting to see several replies pointing out minor issues that may or may not have been bugs before someone finally(?) saw the critical bug. This wasn’t an isolated issue – I sometimes see testers so anxious to find a bug that they force the issue, trying to make a bug appear where there isn’t one, that they miss a bigger issue right in front of them. Other testers, however, seem to always be able to hone in on the biggest, most relevant issues.
So what is it that makes some testers zero in on critical issues, while others get lost in the weeds? Domain knowledge is a small part of it, but certainly not a critical factor in my observations. Critical thinking is a bigger part of it – as is experience, but I haven’t yet figured out to help testers consistently get out of the weeds.
Certainly not a huge issue, but if you have thoughts, please let me know.