How do you deal with the “why were you even looking there?” question when you report bugs?
We’ve all heard this at some point, have you discovered a good way to address this?
You can read the LinkedIn and Twitter answers if you’re looking for inspiration.
One of the twitter answers was “Because I sensed there was a bug there and I couldn’t help myself.” And that was my favorite answer from the bunch.
If the person with the question is technical (i.e. an architect, designer, coder, other tester), I will typically walk them through the steps I used to get from “Test function A” to "There’s a problem in function “E”. It usually amounts to “I was paying attention to more than just the test and I saw a rabbit. The rabbit needed chasing, so I chased it down the rabbit hole.”
I find that the team appreciates when we answer such questions openly and honestly.
Saw this on another social platform, but was afraid to weigh in at the time. THanks for sharing @mcgovernaine
I like to explain what I could smell was bad about the area I was fishing for a bug in. This helps developers to learn how to either hide their bugs away in the UI so I won’t find them in future, or better yet, learn the same trigger/heuristic and apply it themselves.
If I cannot explain it, it’s just magic, and nobody learns anything. And this applies not just to UI’s but to any interface. We all test interfaces in some flavor or another.
“If I cannot explain it, it’s just magic”
Ah, that’s good. Why was I even looking for bugs there? “Because that old Tester Magic said I should.”
If it is a bug, I will explain that it was a part of exploratory testing I was doing and based on past experiences I could guess error prone areas and hence I went there to test the functionality.
I think there is some truth in using past experience to help you find bugs, but that is not a heuristic that will improve product quality significantly, because it’s nothing new. Everyone knows to look in the same area as last time, bugs are like animals in a desert, most of them will be around the same watering holes. But all you might find is more of the same low value bugs, a bit like dredging. Bugs and are often there because they are in functionality that nobody cares about and that do not impact the business.
To explore and find bugs that impact the business you need a map that leads you to bug watering holes that are not yet charted, and you need to find them before the customers find them. And that means looking in areas where an environmental factor has changed (an external stimulus of some sort.) Elizabeth H’s “Explore it” book on exploratory testing covers a few heuristics or tactics to employ, as well as tips on how to explain why and what you did, to your team too. Use past experiences to find new maps, but do this at the problem-domain level.
For example: I found a bug in text font sizes while checking product accessibility, so I then go hunt for LI8N/L10N bugs in case some languages don’t fit into the controls.