Raise problems NOT bugs!

Recently, I tweeted the following:

When communicating something found during , refer to it as a problem not a bug. You would be surprised how more engaged others get.

The reason I wanted to blog on this topic, is that I feel strongly in the value we provide as testers, one of which, is the ability to investigate and raise potential problems with your team(s).  I like to use the word ‘problem’ and not ‘bug’.  I will expand on why…

REASON 1: Bug – assumes we are quality gatekeepers.

Testers should not be the team member that unilaterally decides what it is and what is not a bug. We should be relaying observations or potential problems and allowing the team to investigate and make determinations on whether they should classify something as a bug. Teams have multiple disciplines with various skill sets and points of view (development, business, UX, etc), utilize them to help make this classification.

REASON 2: Bug – may not indicate you are seeking assistance.

Identifying something as a bug is not necessarily a cry for help or a request for assistance from your team. A problem can signify an alert to the team to get involved (which also leads into #3).

REASON 3: Bug – may assume the necessary due diligence has already been done.

When you relay to your team that you have found a bug, it can be assumed that it is indeed a bug, that you have done your due diligence and it does not need further investigation. This may lead to erroneous bug reports, unnecessary churn, or just a complete waste of time. Getting the whole team involved helps prevent these from happening and more importantly, trying to prevent them from happening again.

REASON 4: Bug – denotes something that needs fixing.

Again, this classification assumes that it is a problem that needs fixing.  But does it?  How do you know for sure?

REASON 5: Bug – assumes the customer would have a problem with what you have found.

Calling something a bug can be assumed that a real-life user of your product would also find a problem with what you have found. But would they?  How do you know?  What you think may be a problem, for them it may not be. Find out this information if you can.

REASON 6: Bug – can be downer to developers.

Calling something a bug can be a downer for a team and especially a developer. An assumption can be made that something was missed or implemented incorrectly by the developer. However, the problem may have originated from bad design, ambiguous or missing requirements, out of date specs, poor UX, or improper/misguided testing.  Raising something you find as a ‘problem’ instead, gets the whole team involved in the investigation, resolution and root cause. It does not finger point or improperly identify sources of the problem. Believe it or not, many people on your team love to investigate problems as much as you do!

REASON 7: Bug – can inspire a blase attitude.

An important aspect of what we do, is to find potential bugs for sure. But identifying something as a bug, can lead to blase attitudes among team members. “Ok, you found another bug, send it back to the developer who worked on it”. This is where you want your team members to become more engaged.  I have found when I identify something as a problem, the whole team wants to know what it is and get involved. Conversely, when I have said I found a bug, team members not associated to that issue, do not have the same level of engagement and curiosity.  Keep them curious and engaged!

This is not to say you should never raise bugs. Of course, there are some that may be obvious. But try getting in the habit of referring to everything you find as a problem, potential problem or observation and make note of the engagement levels of your team. Hopefully they go up. If they do not seem to go up, do not revert back to usurping your throne atop the quality gate.

Keep at it until it works.