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.

  • 57
    my boss [is] unwilling to use the ticketing system to report any bugs && Bugs need to be reported so I can put the time into my timesheet. Does your company require you to fill your timesheet? If so, does your boss not act by your company's standards?
    – Bernat
    Commented Aug 14, 2018 at 11:50
  • 21
    Do you have any idea why they won't enter bugs via the ticket system? Sounds like they are familiar with it so that isn't the issue. If you ask your boss why he won't enter bugs, what does he say?
    – DaveG
    Commented Aug 14, 2018 at 12:59
  • 74
    Is there something preventing you from entering the bug report on their behalf? Commented Aug 14, 2018 at 13:39
  • 20
    Possible duplicate of Coworkers bypass the support ticket system and call me directly for help
    – shoover
    Commented Aug 14, 2018 at 13:42
  • 13
    Something's not quite adding up here, if your colleague uses the ticket system daily but instead of using it for your project gets "emotional" and "rants". We need more of the story. Commented Aug 15, 2018 at 9:49

21 Answers 21


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.

  • 165
    While this is generally good advice, you want to set the tone without making them out to be children or having a condescending manor. You want them to work with you and play your game, so act accordingly.
    – li x
    Commented Aug 14, 2018 at 10:54
  • 52
    Agreed with lix. These are coworkers, not subordinates. In fact, one of the problem people is the OP's boss. Taking that tone with your boss would be a BIG no-no.
    – David K
    Commented Aug 14, 2018 at 12:08
  • 24
    I would like to add a different perspective. In the hospital where I work as a doctor, we were summoned to test a new electronic patient file system. It did not work great. The developers required us to adapt to their needs, instead of the other way around (we felt we were doing them a favour, while they made us feel we should be happy to help them). This caused hard feelings toward the developers. If you really want the bug filed, make it easy for them or do it yourself if that saves you time.
    – Jasper
    Commented Aug 14, 2018 at 12:36
  • 66
    This made me not upvote: "Send her the email reminders for at least a week". I suggest "send a reminder after a few days". You're not her handler. You have proof that you tried. it's her responsibility now. This is in line with li x and David K
    – Martijn
    Commented Aug 14, 2018 at 12:40
  • 16
    This is pretty much disastrous advice. It will lead to resentment and co-workers will use such attitude as an example of why it is difficult to work with developers.
    – teego1967
    Commented Aug 14, 2018 at 16:24

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.

  • 14
    The woman who ranted at me uses the ticket system daily. Commented Aug 14, 2018 at 11:33
  • 5
    @user1261710 Then she really has no reason to complain... All the other answers still apply
    – Elmy
    Commented Aug 14, 2018 at 11:36
  • 80
    @user1261710 Just because someone uses something, does not mean they enjoy using it. As a developer of 20+ years, I still hate logging bugs. Most ticketing systems are unwieldy, don't default fields that should have obvious defaults, have far too many required fields, and end up requiring 4x as long to report a bug as doing it in person. I still do it, because I understand the need, but I also completely understand why non-developers would not want to. So focus on the parts of this answer that encourage you to make it easier and to communicate the benefits.
    – Nicholas
    Commented Aug 14, 2018 at 14:33
  • 8
    @Nicholas: "Just because someone uses something, does not mean they enjoy using it." Regardless, it shows that not only is she capable of using it, but does actually use it, so questions need to be asked about why she's only not using it for this particular project. Something is not quite right here. Commented Aug 15, 2018 at 9:54
  • 3
    @LightnessRacesinOrbit I do see your point, but the reason they're using it for other tasks could be because there's no easier workaround (like what they're doing in this case), or that not using it for those tasks will cause too many negative repercussions for them, or any number of other reasons. I'm not saying that they're valid reasons. But if the majority of users are skirting this process I think resolution becomes more important than blame, even if these users truly are at fault.
    – Nicholas
    Commented Aug 16, 2018 at 14:25

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]

  • 94
    Note the listen, I’d love to fix that, but I’m going to forget. Can you enter a bug in the system? - politeness is the key part of this answer.
    – Joe
    Commented Aug 14, 2018 at 16:33
  • 5
    Agreed. As a dev, if it's not in the bug tracking system, I don't know about it. So, it won't help anyone if I get yelled at for something I don't know about. Responding in kind to someone how is yelling isn't usually going settle them down, so politeness is usually the right treatment. "Ok, I see this is a problem. Why don't you take me through the steps to reproduce the issue and we'll start a ticket..." After 1-2 times of this, hopefully they get the idea to just start a ticket and avoid your 1000 questions "for more info to put into the ticket." :-> Commented Aug 14, 2018 at 17:18
  • 9
    The thing is, the OP is not talking about "the QA department". The OP is talking about something more akin to, in Mr Spolsky's lingo, "hallway usability testing". Is it reasonable to expect non-QA folks to fill out turgid bug reports? Probably not unless it is specifically a part of their job.
    – teego1967
    Commented Aug 14, 2018 at 18:15
  • 5
    @teego1967, to quote another Joel Spolsky article with my bolding added: "Avoid the temptation to add new fields to the bug database. ... It’s very important not to give in to these ideas. If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs “formally” is too much work, people will go around the bug database."
    – Wildcard
    Commented Aug 15, 2018 at 19:34
  • 2
    @Wildcard, yep, that's exactly what happens in many places. Before you know it the form becomes a completely unusable mess for everyone except the person who created it.
    – teego1967
    Commented Aug 15, 2018 at 23:51

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.

  • 1
    What if you're fine with forcing your colleagues to comply? :P Commented Aug 14, 2018 at 17:50
  • 1
    @PoloHoleSet, lots of people are OK with that. It does use up good-will, however, to force people to do stuff. Don't expect favors or consideration in return if you force people too much. It will be better to find the root cause and address that rather than pretend it's all their problem and dismiss bug reports which aren't in the tracker.
    – teego1967
    Commented Aug 14, 2018 at 18:10
  • 2
    Totally joking, from the jaded person who has to do support and fix bugs side of things. Commented Aug 14, 2018 at 18:13
  • 6
    Upvoted for the third paragraph. We have such an "alpha" user, and it's wonderful. Commented Aug 14, 2018 at 19:29

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.

  • 2
    And if people make an issue about self-entered bugs you can fill out a paper form while they are ranting and ask them to sign it once they are done ranting and use that as proof of the report. If they refuse to sign then tell them you cannot fix the bug otherwise. Commented Aug 14, 2018 at 13:18
  • 5
    If OP enters the bug for this colleague, that'll just encourage her and all the colleagues to always come and rant rather than enter the bug themselves (which is the official way things should be done).
    – Dragonel
    Commented Aug 14, 2018 at 23:56
  • 5
    This is not how it works. Producing software with few bugs is only ONE part of a developer's job. With your rationale, "I shouldn't bother to comment code or enter good commit comments. As long as my code has no bugs, all is fair game." Everyone has a different role, and there are procedures. Doing other people's job just because they refuse to follow procedures is a sure way of getting yourself tangled in another mess later on. Especially when you didn't understand the bug correctly and tomorrow the same person will come back ranting even louder.
    – hjf
    Commented Aug 15, 2018 at 13:59
  • I didn't say you shouldn't do your job. I said you shouldn't worry about whether the other person is doing their job. What isn't your job is managing your colleague or enforcing company procedures on your peers.
    – Peter
    Commented Aug 15, 2018 at 14:27
  • @Dragonel: Not necessarily. A very possible outcome is that on the one hand, the developer ends up working more efficiently, because the developer's self-written bug reports say "after clicking X in module Y, error message Z appears", whereas the bug reports on the same issue by unwilling colleagues read "the X feature fails". And on the other hand, colleagues who feel that the bug reports the developer writes themselves lack in accuracy (e.g. because the dev lacks some domain knowledge on representative use cases) suddenly have an actual incentive to write the reports themselves. Commented Aug 16, 2018 at 12:06

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.

  • 4
    I basically agree with you but OP said that even the manager is sometimes unwilling to write a bug report so this is probably not going to help in the long run :/
    – dontbyteme
    Commented Aug 14, 2018 at 12:01
  • 10
    When management themselves don't follow rules, and fester the toxic environment, it is time to either escalate or polish the CV. Probably both. @dontbyteme Commented Aug 14, 2018 at 12:27
  • 2
    @dontbyteme: "the manager is sometimes unwilling to write a bug report" - strange as it sounds, a complete unwillingness to file bug reports oneself and full commitment to enforcing a "do not make any code changes unless you have an issue tracker item for it" policy can very well coexist in real life. Commented Aug 16, 2018 at 12:03

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.

  • 8
    What if the company's timesheet procedures require that the bug ID(s) be listed? "Spent 15 minutes fixing bug 641. Spent 30 minutes fixing bug 832" and so on. Similar to how most (programmer) timesheets require that the project name or code be listed when they're doing regular development work.
    – alroc
    Commented Aug 14, 2018 at 11:05
  • 1
    @mhoram_psprep: Getting paid is important. To the company, getting the testing done is more important, but to the individual getting paid is more important. Participants not only need to understand the process, they need some reason to go along with it. Commented Aug 14, 2018 at 19:28
  • 1
    That is why I included the last paragraph. The point of the Alpha testing is to improve the product. If they don't understand that they shouldn't be participating or they need training. Commented Aug 14, 2018 at 19:34
  • 3
    @alroc If the timesheet expects bug IDs, then there's nothing stopping one from creating a ticket ID as needed for the reporting, even if no discussion happens in the ticket.
    – Ezekiel
    Commented Aug 14, 2018 at 21:49
  • 2
    Although not stated, source code commits may also require a bug #. Last place I worked was like that, each commit had to include the number of the project or bug it was committed against. At the start it seemed a bit draconian but it did help in keeping track of things. So he may literally not be able to fix a bug without a bug report.
    – DaveG
    Commented Aug 15, 2018 at 13:12

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.

  • 1
    The OP could insist that everybody else use the ticketing system, and enter bugs for his boss only. Commented Aug 15, 2018 at 15:45
  • 2
    The boss is the heart of the problem. No one else will do it if they see the OP's boss doesn't bother. This is a boss undermining their own staff problem. Commented Aug 16, 2018 at 9:31

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.


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.

  • 2
    We use JIRA. All you have to do is enter the steps to reproduce the bug, and maybe attach a screenshot. But people still don't. They paste a screenshot on an email and say "I found this problem". If they have even the smallest "title" like "leader" (a leader is not even a manager), they will also add opinionated comments about the system. Because of these people, the company hired a person whose job was taking those emails and enter them into JIRA.
    – hjf
    Commented Aug 15, 2018 at 14:05
  • 3
    As I long-time developer I love reporting bugs in a bug reporting system. :D Commented Aug 16, 2018 at 14:42
  • @hjf and that is probably the correct thing to do - saves time for the users and so saves money on them and thus provides enough money for the new hire.
    – mmmmmm
    Commented Aug 19, 2018 at 16:00
  • @Mark the person was laid off, paid full compensation, and hired again 3 months later. The clients (our clients are multi billion dollar telcos) threatened to terminate our contract if said position wasn't restored.
    – hjf
    Commented Aug 20, 2018 at 4:55
  • @hjf sounds like your company learnt the important lesson that no system can replace a good human administrator :-)
    – Aaron F
    Commented Aug 20, 2018 at 10:33

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.

  • 3
    This is true. The whole process of using Rally or JIRA or whatever to track work is a PITA - and those are among the better ones. (Don't get me started on ServiceNow.) It seems like annoying busy work … until the day your department VP tells you all he tracks it closely and uses all the summary numbers in there to go to the board to get his budget for next year ...
    – davidbak
    Commented Aug 14, 2018 at 22:59

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.

  • Whether the developer sits with the user to see the bug demonstrated is not related to whether there's a ticket system or not. I'd never resolve a case because it was unclear. I ask more specific questions and perhaps pay a visit to the user, and this is with a good bug reporting system. I don't think this answers the question. Commented Aug 14, 2018 at 19:26

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.

  • 1
    He should be thankful that people come to him (any random developer) and RANT about a bug? I'm sorry, do you even work for a company? It seems you are unaware of how toxic some people are, especially the ones that have "job titles" higher than yours.
    – hjf
    Commented Aug 15, 2018 at 14:08
  • 1
    As a developer, getting a short description of a bug, with a demonstration, is sometimes far better than trying to interpret a typical non-developer's description in a "formal" bug report, especially if they include a "screenshot" that doesn't actually show the bug. Asking the user to try to record their screen will probably use far more of their time as well. In an organisation, using extra time from other people's "budget" is actually less efficient overall. Commented Aug 19, 2018 at 23:37
  • It's part of employment to file tickets. You should be grateful to non-employees for filing tickets, but the sole purpose of employment is to improve the product. If it's not their job to file tickets then who's is it?
    – yeerk
    Commented Dec 8, 2023 at 23:00

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.


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


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.

  • 1
    Including the fact about the coworker refusing to write bugs is a way to get that person against you. Management is more likely to side with you if you DON'T fix a non-reported bug, than if you "snitch" on a coworker. They are more worried about people "not fighting" than about getting a quality product.
    – hjf
    Commented Aug 15, 2018 at 14:14
  • @hjf That sounds like horrible management...but also I think you might be right. I'll edit my answer. I'm still adamant that they should just write the bug themselves, but taking out the part where they snitch should help.
    – Zibbobz
    Commented Aug 15, 2018 at 14:53
  • 1
    @hjf I wouldn't think of it as "snitching". You can just enter the bug as "Joe Smith reported clicked twice causes a system crash". Just the facts. It's important to know who originally found the bug in case you need more details. I don't think anyone could hold it against the person entering the report that they included the name of the person who actually found the bug.
    – DaveG
    Commented Aug 16, 2018 at 17:57

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.

  • 3
    Drag them into a bug triage meeting and force them to watch everyone else's bug reports get prioritized over theirs because theirs isn't in the tool!
    – coagmano
    Commented Aug 15, 2018 at 6:55
  • This assumes the person can decide what to do with their time. That they have time for meetings, that the other persons will accept to be dragged into a meeting. Considering the original post said the BOSS refuses to enter tickets, we know how things go in this company: Boss gives verbal orders and then when things go wrong, they throw you under the bus. And they're always neck-deep in water. Yeah, this is not going to happen at the kind of workplace OP described.
    – hjf
    Commented Aug 15, 2018 at 14:11
  • This whole thing reeks of passive-aggressiveness. Allowing each person to do what's suggested, when they come to you to report the bug, is making better overall use of both your and their time :o) Commented Aug 19, 2018 at 23:39

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".


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."


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.

  • 4
    "If you've got a problem, you want to be listened to, actively." - ironically, the rant of the person at the desk will be forgotten when they leave, whereas a ticket stored permanently on the bugtracker will receive some individual, active attention at some point. Commented Aug 16, 2018 at 17:06


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

  • 7
    People that like to rant about bugs wont be pleased to see that "the 'incompetent' developer is trying to make his work a game instead of fixing his software". I worked at an office where they tried something similar, the situation got only worse.
    – Mixxiphoid
    Commented Aug 14, 2018 at 11:24
  • If people finding the bugs don't understand the role of a developer, they likely shouldn't be taking up a position on the testing team either - ideally you'd have a dedicated testing team who know exactly what they're doing and why. You can't fix broken workplaces... Commented Aug 14, 2018 at 11:26
  • 3
    When you gameify a system like this, people will find ways to exploit it for their benefit. Who decides what a "valid" bug is? How do you handle a person reporting 4 "bugs" which are the same problem?
    – alroc
    Commented Aug 14, 2018 at 12:27
  • 1
    Terrible idea. If people get something additional then they will find bugs (that might not even exist) in order to 'game' the system.
    – JazzmanJim
    Commented Aug 14, 2018 at 13:39
  • 4
    Relevant Dilbert: dilbert.com/strip/1995-11-13 . Commented Aug 14, 2018 at 16:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .