How to handle colleagues who are unwilling to write a bug report?

Question

I'm working as a software developer at a small-ish company (~50 employees).

My main project is a mobile app. I have most of my colleagues on the alpha test channel and customers do not have access to this channel.

The problem is that a few of my colleagues and my boss are unwilling to use the ticketing system to report any bugs.

Just last week my colleague thought she seen a bug and ranted and raved at me for 5 minutes and I told her to write the bug down in the ticket system. She would not. Some of my coworkers become extremely emotional when they see a bug and would rather rant about the bug instead of reporting it.

Bugs need to be reported so I can put the time into my timesheet.

The company has one QA person that looks at the app exclusively but he also does other work.

Note: the woman who ranted at me uses the ticket system daily.

Answer 1

Tell her as it is: She didn't report the bug, therefore the bug does not exist. She just wasted ten minutes of her time and your time ranting about the bug. And tomorrow, you send her an email reminder. That you think she had problems, but there is no bug report in the ticketing system, so she needs to add this. Send her the email reminders for at least a week.

Tell her also that ranting about bugs is totally unacceptable. There will always be bugs, that's a fact of life where software is developed, and going on a rant about it can only upset people (it wouldn't upset me, because I would interpret it as her being stupid, not as some bad bug happening that shouldn't be there).

And the next time she starts ranting about the next problem, you cut her short after five seconds. You tell her that her job is to put the bug description into the ticketing system, that you are not going to accept any bug reports in conversation, and that you most definitely don't accept her ranting. Then you walk away, or if it is your desk, you tell her to walk away.

Answer 2

In addition to "tell them that you cannot fix bugs that aren't reported" (as covered in recent answers) you need to make reporting a bug as easy as possible. Most non-IT people feel intimidated by the prospect of having to use the ticket system and think it's far too complicated for something they can simply tell someone.

If a colleague starts ranting, show them the ticket system (where to find it) and file the bug together to show them how to do it. If possible, create a template with the most important information you need:

• Name of the app (you won't believe how many people forget that)
• What did they want to do
• What/where did they click
• What happened instead of the desired behavior (the actual bug)
• Add a screenshot if possible
• Name of the bug reporter for call back

In addition, encourage colleagues to report bugs. Make it clear to them that reporting a bug is good, helpfull and has a positive outcome. Some might feel like betraying you by revealing "mistakes" you made.

Answer 3

Taken from Joel Spolsky, co-founder of and CEO at Stack Overflow; who wrote on his blog:

For example, suppose nobody on your team can be persuaded to use a bug database. Don’t let it bother you. Just keep your own. Enter bugs that you find in your own code. If you find a bug that somebody else really should fix, assign the bug to them using the bug database. If you have good bug tracking software, this will send them an email. But now, you can keep sending them emails if they don’t fix the bug. Eventually, they’ll see the value of bug tracking and start to use the system as it was intended. If the QA team refuses to input bugs to the bug tracking system, simply refuse to listen to bug reports through any other channel. About the three-thousdandth time that you say to people, “listen, I’d love to fix that, but I’m going to forget. Can you enter a bug in the system?” they’ll start using the database.

_{[Emphasis mine]}

Answer 4

One thing that many non-developers have an aversion to is bug-tracking systems that are strictly interfaced for the purposes of developers. These bug-trackers typically use a "one-size-fits-all" massive single form with far too many non-applicable or non-intelligible drop-downs/fields/radio-buttons. These things are daunting to fill out, and moreover, they're frequently unanswered or just closed in a way that seems capricious.

If you want to address the problem without simply forcing your colleagues to just comply, consider ways of streamlining the bug-report system and making it more responsive. This could be as simple as writing a short sentence to the person who reported the bug (instead of merely selecting a status on a dropdown). Are you collecting things like the build number automatically or are you making the users find it? Do the users know how to take a screenshot on their phone (and get it to the tracker)? You would be surprised how many people can't. These seem like trivial hurdles, but if it takes research to "figure out" how to fill out the bug report, a LOT of people just aren't going to do it.

Alternatively, you may try to work with an "alpha" user(s) who is willing to be an intermediary for the rest of the users. Have this person fill out the actual bug reports on behalf of others. This way, you get your tickets and the users get to talk to a human and the problems get noticed and solved.

Answer 5

Enter the bug report yourself. If you can extract enough information from the conversation or email for the bug to be reproducible, great. If not, at least you'll have the ill-defined bug on record to link with other occurrences in the future.

Why do I say this? Your job is to produce a piece of software with as few bugs as possible. That means bug reports are something you should desire very much. If you make the process too cumbersome, the only people who will report bugs will be the ones whose primary job it is to do so, and your product will suffer.

Your opinion of the difficulty of using the bug tracker is irrelevant: you apparently have more than one user who don't like to use it. So, graciously accept their input, create a bug in the tracker, and make them the originator if possible. If you can't, then note that it was reported by so-and-so, and move on with your job. Or, ask your QA person to call the reporter and enter a bug if real.

The issue of your colleague not following process is not your problem. It's your colleague's manager's problem. And since you've said that even your manager doesn't always follow this process, focus on ways you can get your job done.

Answer 6

Just email them with a polite request to report the bug into the ticketing system and cc your manager. If it doesn't appear, follow up, with your manager cc'd.

It's the managers role to ensure staff are using tools correctly, it's also their role to make sure you're not being personally confronted and ranted at by people outside their team. You don't have the authority to enforce it, and it's not your job to try.

Answer 7

My main project is a mobile app. I have most of my colleagues on the alpha test channel and customers do not have access to this channel.

So far so good.

The problem is that a few of my colleagues and my boss are unwilling to use the ticketing system to report any bugs.

Maybe not as good as it seemed.

Just last week my colleague thought she seen a bug and ranted and raved at me for 5 minutes and I told her to write the bug down in the ticket system. She would not. Some of my coworkers become extremely emotional when they see a bug and would rather rant about the bug instead of reporting it.

Now looking back at the first quote a question that pops into my head is who put your colleagues into the alpha test channel. The purpose of their testing is to generate the bug reports. Now there will be some people who can't dedicate as much time as they thought to testing, or use so little of the product features that they barely test the program, but you need to have the testing done by people who will complete the cycle.

Bugs need to be reported so I can put the time into my timesheet.

No they don't. Bugs need to be reported so the quality of the product improves. The time sheet is how you record your hours. The bug reporting system is how developers know what needs to be fixed. The goal of the alpha tests is to insure the bulk of bugs are not making it to customers.

The company needs to make sure that people either assigned to the alpha testing, or those that volunteer, know what is expected of them. They need to know deadlines, processes, how much time is involved, and what types of reports they need to produce. They need to know if they are expected to test all or just part of the application, they need to know what to do if they test part x and they have no bug to report.

Answer 8

The problem is that a few of my colleagues and my boss are unwilling to use the ticketing system to report any bugs.

None of these address your boss also doesn't want to do this.

I would recommend three things.

First, talk to your boss and understand why your boss is unwilling to use the ticketing system. At the end of the day something is off here. You need to fill out a timecard accurately but your boss is actively working against your ability to do that - does your boss even know this?

If your colleagues are literally as you say "ranting" at you for five minutes and your boss doesn't care, your boss sucks. I personally suspect there is much more to this story than what you've presented here but regardless you need to talk with your boss.

Even questions like, "Bob doesn't want to submit bug reports, how do you want me to track that work?" is meaningful.

Second, do some serious reflection about the process your colleagues have to go through when reporting a bug. There are teams I work with that I have given up writing bug reports for because of how frustrating that process is.

I more or less have delegated the "is this a bug?" question to them as I have had way too many negative experiences working with them - whether it's closing the ticket as "won't do" or changing a bug report to a feature request or arguing with me about whether it's a bug, I only have patience for so much of that before I stop caring. I report the functionality to them via chat and let them decide if it's a bug. I have wasted far too much time trying to "prove" things to them and ultimately it's not my responsibility to make their product better.

Last, if the situation is actually what you are describing here, your workplace sounds really crappy. But - there are likely two sides to the story and what we're all missing (including you it seems) are the other story.

Empathy is important. Multiple coworkers, including your boss, "ranting and raving" rather than reporting a bug properly suggests there is a major lack of empathy somewhere in the interactions.

Answer 9

Mention it, say to your colleagues that

If you don't use the ticketing system I can't fix it because it's not going down in my timesheets.

This way they are going ticket the bugs otherwise it'll seem that bugs aren't "Found" and it is them who are at fault not you. So they either ticket the bugs or let bugs go into a live app. This puts the ball in your court.

They may then go to your manager and say that you're not fixing the bugs but you can then just reason with them there and it is likely that your manager will take your side and ask them to use the ticketing system.

However to avoid any of the commotion just tell your manager.

People are finding bugs and I am fixing them but they refuse to log it into the ticketing system so that I can mark it against my timesheet therefore my timesheets are not accurate.

Answer 10

As a long time developer - I hate reporting bugs in a bug reporting system. They all require entry of multiple fields nearly all of which I don't know the answer to or don't care about. And they're slow too. Plus when I'm done the developer always closes it "can't repro" anyway.

I, using your app, would greatly appreciate a button right there in the app that would report the bug in your app. It would take a screenshot, know its own damn build number, serialize the record of the last 100 UI interactions or whatever else would help you repro the problem, and also add other stuff of interest to you the developer that it has right there in RAM at the moment, and, maybe, allow me to optionally enter a comment.

Then we'd all be happy.

Answer 11

I worked for a large IT company in the past and many of the employees on a particular team refused to use the ticketing system. They lost their jobs eventually due to redundancy.

No record of the work that needs to be done in the system, then workforce planning has no record to base their future estimates on.

Systems are there for a reason not for fun and people don’t always think of the bigger picture and see this as another hurdle they have to cross to get their job done. Emphasise the importance of logging work so they can account for their time.

Answer 12

While I agree in general with the other answers, in addition I want to add another viewpoint.

Of course you and your manager can force your colleagues into writing bug reports, but if these colleagues are not developers or familiar with ticket systems, you could end up with lots of useless tickets a la "stupid feature X does not work.". You could then send them the ticket back with "unclear", but this easily leads to a useless, infinite cycle, which helps you nothing.

Another approach would be to sit down together with them to reproduce the bug and you create a meaningful bug report afterwards. This may sound more time consuming, but has several advantages:

• your colleagues feel their issues get addressed
• your colleagues get educated what info you need to fix bugs
• you get a meaningful bug report with all the necessary info
• you spend less time triaging incomplete tickets

In the end this could be a faster and more satisfying approach.

Answer 13

Alternate view point - be grateful that you have colleagues who are engaged enough to provide you with direct input on the product.

Yes they should write good bug reports, but not everyone does that. And chances are, as a developer, you will write a better bug report yourself.

I would therefore recommend the following approach in future:

• Make it clear you are grateful for your colleagues input. Or to put it another way, make it abundantly clear that you do not consider them a problem that needs to go away. This might be the perceived reaction if you say "file a bug".
• Explain that it will be the best use of everyone's time if you sit down and write the bug report together, there and then.
• Work through your own bug reporting template/checklist.
• Capture absolutely everything you can about the bug, while you have the person's attention and ability to reproduce it in front of you, while the issue is fresh in the reporter's mind. This is particularly important for mobile apps, where you might not have access to a test device which reproduces the problem, or it might be an issue that can only be reproduced on a specific installation instance of the app.
• Make sure the reporter is subscribed to updates on the bug via email, so they can see it making progress through the system.
• Thank your colleague for their input and say how much you value "hallway usability testing" (as Joel puts it) and that they care enough to report bugs. Say you wish more people in the company did this.

In taking this approach, you will be perceived to be open and receptive to reports, you will educate the reporter on what a good bug report looks like and you will both feel like you have achieved something as a team.

Both the product and workplace relationships will benefit from adopting such an approach.

Answer 14

My first job had a similar problem. My group made software that some of our engineers used and they sat right outside our room. They were all used to just coming back and telling us when we had a problem which resulted in some things being forgotten about.

We started a ticket system to combat this, help keep track of things, and remove interruptions. It took a while but eventually we got people to use the system by always saying "Did you put a ticket in the system?" and not working on any issue until it was in. We also would remind them that this isn't just for our benefit its also so their issues wouldn't be forgotten about. If it was recorded then it would eventually get done.

Answer 15

Are the colleagues involved developers? If yes, them it should be easy to explain what the process is and why it helps to have everything organized. If not, they might not be familiar with bug tracking systems and not understand why they are useful.

They have been asked to help test the app, which means they see this very different than a tester, for example. A tester knows what the process is and follows the steps. A colleague asked to test the app will assume every bug is a big problem and will assume they can just tell you about it and explain personally why it's a big problem, instead of adding it to a tracking tool.

Find what they are comfortable with

If they feel better at adding the description to a document, give them all access to a new google doc for that. Then review the issues and add them yourself to the bug tracking system, if they really are bugs. That should not take too much time. It might be better than having them fill insufficient details in a bug tracking tool.

The point is to get people to submit valuable feedback, not to get them to use the tools you are used to

Answer 16

If the top answers still will not get your co-workers to write their bugs and send them to you in the ticket system, here's a surefire way to make sure your work time is allocated to the ticket system.

First, write down everything that your co-worker tells you about the bug. If possible, get them to email you about it so you have something to read.

Next, write out the bug yourself.

Finally, fix the bug - if you know about it and you are expected to fix it, then fix it.

This does a couple of things for you - it puts the bug in the ticket system to show that you've allocated coding time to it, and it puts your time spent writing up the bug in the system as well - essentially, the time that your co-worker 'wasted' telling you about it in person becomes billable time for you.

You should continue to encourage your co-workers to write their own bug reports since that is what they should be doing, and you shouldn't discourage it. But in lieu of that, if your real goal here is to have it in the system so that you can record your time spent working on it, just write it yourself, and reap the credit for both writing and taking care of the bug.

Answer 17

It's possible your colleagues simply prefer human interaction over entering data into a tool.

So drag them into a recurring meeting. If your company is not meeting-friendly (perhaps you don't have good conference rooms with large monitors?), walk to each person's desk and do this on a 1:1 basis:

During this meeting you open up the bug-tracking tool on your own laptop and have them dictate the bug description to you so that you can enter it into the tool. Take this opportunity to have them show you the bug or clarify any necessary steps to reproduce it.

Remember to include in your timesheets the time you spent documenting each bug, that's just an integral part of fixing the bug.

Practice the art of keeping a straight face while listening to their rants (provided they are not abusive). This is an important skill and the extra interaction with these people may seem like a waste of time to you now, but it will help later in your career when you eventually decide you want a better job.

When you fix a bug that was reported with a lot of emotion, walk over to that person and let them know it's been fixed, and if they would kindly verify and confirm it works to their satisfaction so that you can close the ticket.

Answer 18

An orthogonal solution:

Add a "report bug" button to the alpha-test version of the software which automatically collects important data and files the bug report.

Add a few simple text fields: "What were you trying to do?" "What did you expect to happen?" "What went wrong?"

(This won't help, of course, if the problem is that the app hangs or crashes.)

Let the power users refine the report and let the ranters just hit "submit".

Answer 19

I have dealt with this for 20 years and basically the same answer the past 19.

You tell them, "Look if that bug is important to you I would get it in the ticketing system as quickly as possible. My team and my management allocates priority and time as they review the system for bugs. If your bug isn't in there at best it is high priority in the next cycle. I can't really work on fixing things without a proper OK. Also the entire team needs to understand the full impact as it might effect other things - meaning whatever you just told me everyone needs to be able to see which may make the problem solving quicker."

Answer 20

Ticketing systems and end users are incompatible. People hate them (for many good and not-so-good reasons). If you've got a problem, you want to be listened to, actively.

Maybe you should somehow emphasize that your colleagues are an active part of the development, and not mere users. Send out bug and dev statistics each Friday, mention people by name who have helped by finding critical bugs, maybe even do a little ranking (don't let it get too competitive though).

Also, are you maybe able to improve the UI of the ticketing system? Cut all the technical details, a text box and (very) few categories to choose from are enough. Make it as easy as possible to report a bug the correct way.

Answer 21

GAMEIFY IT!

Everyone loves points, because points mean prizes**!

Simply have a scoreboard of 'Most found (valid) bugs this week*' along with special mentions for particularly weird/interesting bugs to challenge everyone.

*Only bugs reported correctly can be counted!

**Prizes may only be compliments