Is this a bug?

This is a fairly common question that pops up in projects. It could happen when requirements are ambiguous, or when the behavior could pass off as meeting the requirements and folks are on the fence about it, or when there’s a change in the requirements or implementation that didn’t get communicated across timely enough, etc. It just happens.

But as someone who has a testing background, there are admittedly times when I don’t like it when testers ask me this question. In general, I think it’s when very little to no analysis goes into the understanding the bug (or possible bug). Especially when there are provided references.

If I were the one testing, I would expect me to exercise due diligence. I have to try to crosscheck against the user story and other provided references. I expect me to understand what I’m supposed to be testing. I’ll need to try to do the RIMGEN / RIMGEA stuff. I won’t just say “I did this and this, this happened, is this a bug?” I will try to answer that question myself. And if it’s still not clear and I need to consult with a team mate, I would phrase my question slightly differently. Probably somewhere along the lines of: “I did this and this, this happened. It might be a bug because <so-and-so>. On the other hand, <reason why it might not be a bug>.”

The more brains you pull into consultation on this possible bug, the more costly it is. It also takes away other people’s time and focus from stuff that they’re actually supposed to be doing when they’re helping you do that analysis.

That analysis is part of the service we provide as testers. That analysis is part of the value we bring in to the team.