157

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.

user1261710
  • 3,783
  • 6
  • 21
  • 29
  • 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 Aug 14 '18 at 11:50
  • 5
    Yes, there are times when even my direct manager is unwilling to write a bug report even though he uses the ticket system daily as well as some of my coworkers. – user1261710 Aug 14 '18 at 11:57
  • 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 Aug 14 '18 at 12:59
  • 10
    No, I don't know why. He said if it's just something small then can I not just do it then and there but if there is no ticket then I can't do my timesheet or track the issue. I guess instead of logging the issue he wants an immediate response even if it's not an emergency. It does disrupt my workflow though. The other woman could not answer me as to why. She had no answer. They both use the ticket system every day. – user1261710 Aug 14 '18 at 13:03
  • 5
    @user1261710 You need to talk to your boss. The advice below is good, but the top-voted answer for instance can't be used if your boss won't back up your approach, and it sounds like that's not the case. Have you talked to him in detail about how to handle reporting time for unreported issues? Or did he just brush it off? – Lilienthal Aug 14 '18 at 13:15
  • 74
    Is there something preventing you from entering the bug report on their behalf? – Carl Kevinson Aug 14 '18 at 13:39
  • 20
    Possible duplicate of Coworkers bypass the support ticket system and call me directly for help – shoover Aug 14 '18 at 13:42
  • 5
    or How can I convince my colleague to call the help desk instead of contacting me directly? – shoover Aug 14 '18 at 13:43
  • 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. – Lightness Races in Orbit Aug 15 '18 at 09:49
  • 9
    @CarlKevinson Perhaps a good suggestion on the face of it, but this sort of "enabling" only leads to you ending up doing everybody's work for them and for this to become seen as normal. However, there's also a "pick your battles" consideration and this may, on balance, be the best viable option for the OP. Sadly, again, we have nowhere near enough information to judge properly. – Lightness Races in Orbit Aug 15 '18 at 09:50
  • 2
    Are you paid hourly? Is submitting an accurate timesheet essential to ensuring you get paid? – AffableAmbler Aug 15 '18 at 14:36
  • 2
    Do they actively refuse, or do they just not bother doing it? – komodosp Aug 15 '18 at 16:54
  • 1
    Do these users need to be on the alpha channel? Or do you just have them there to increase your testing before release? – jpmc26 Aug 16 '18 at 00:57
  • 1
    An addendum to all answers, would be to expect SOME bugs to reported in person. You are never going to get 100% ticket usage. Even after focusing your efforts on the worst offenders, unfortunately, you will have to resign yourself to the fact that for the rest of your life sometimes people will walk up to your desk, complain about a bug, and then walk away, thinking their job is done. – yeerk Dec 08 '23 at 23:03

21 Answers21

171

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.

gnasher729
  • 169,032
  • 78
  • 316
  • 508
  • 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 Aug 14 '18 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 Aug 14 '18 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 Aug 14 '18 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 Aug 14 '18 at 12:40
  • 7
    This sounds like a recipe for setting up a bad working relationship, and way to ensure that this user avoids using your app whenever possible. – Peter Aug 14 '18 at 15:37
  • 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 Aug 14 '18 at 16:24
  • 5
    Keep in mind with this advice that OP indicated their boss was one of these people. Treating one's boss this way is a great way to get fired. – Joe Aug 14 '18 at 16:30
  • 2
    Part of this answer is about training your co-workers to use the systems in place specifically for the task of bug management. If they don't use it, then it's a waste of the company's money, plus, it's another waste of money and time to have to listen to a 10 minute rant that could be a 3 minute read, and without the personal politics or hurt feelings. Bugs are a fact of life, and unless they are super critical, they need to be addresses as just another fact, to be addresses at sometime later when time and budget allows. – computercarguy Aug 14 '18 at 17:09
  • Nobody should yell at anybody else in a situation like this. Ranting will waste time and cause a lot of hard feelings. When I was swamped with work, and wasn't given priorities, the people who were nice to me got priority, and problems I got ranted at got left for later. – David Thornley Aug 14 '18 at 19:32
  • "Taking that tone with your boss would be a BIG no-no" you joke. Me known to do that and worse. Look up Dan Pena for a more alpha / high performer attitude. – TomTom Aug 14 '18 at 20:37
  • 4
    “She didn't report the bug, therefore the bug does not exist.” The bug did exist. Don’t let processes get in the way of improving the software.

    “Then you walk away, or if it is your desk, you tell her to walk away.” Don’t put barriers in the way of people who are communicating with you. A bug tracking system is there to help the team prioritize and track work. Its not a communication tool.

     – Ben Mz Aug 14 '18 at 21:47
  • 2
    @Martijn "it's her responsibility now" Although I see what you are getting at and agree to some extent, the fact is that this project is the OP's responsibility so it's not really that clear cut. The OP still needs to fix the problem; they can't just pretend it doesn't exist because it wasn't reported in a desirable manner. – Lightness Races in Orbit Aug 15 '18 at 09:52
  • @BenMz There's a tough balance to be found when people are communicating with you not only inappropriately but also ineffectively. I don't know where the middle ground is, but there assuredly is one, and finding some way (disclaimer: I have no idea what that would be in this situation!) to allow the colleague their communication without pandering to their apparent need to do it in the "wrong" manner would be appropriate In my experience this sort of politics & social engineering can, sadly, be half the job of a software developer sometimes :( – Lightness Races in Orbit Aug 15 '18 at 09:53
  • 4
    @JoeStrazzere, yes, the "...therefore it doesn't exist" quip is what makes people red-hot angry and vindictive towards developers. – teego1967 Aug 15 '18 at 23:54
  • 2
    @BenMz: "“She didn't report the bug, therefore the bug does not exist.” The bug did exist." - I agree that goes a bit too far. "She didn't report the bug, therefore the bug was never entered into the queue of things to work on. Consequently, there can be no expectation that it will get fixed." is more accurate IMHO. (Note that this doesn't mean the developer couldn't simply file the bug report in her name, based on the rant.) However, I have to disagree with your claim that "A bug tracking system [is] not a communication tool." - yes, that's exactly what it is. What else could it be? – O. R. Mapper Aug 16 '18 at 12:00
  • @O.R.Mapper Bug tracking systems are tools for tracking work. Most of the features are for that purpose. You can use them as for communicating, however the signal to noise ratio is terrible. – Ben Mz Aug 16 '18 at 16:39
  • 2
    @BenMz: "tracking work" is communication. Conveying to (e.g.) developers what needs to be done. Conveying back to (e.g.) product managers what has already been done. Indicating some context in a partially standardized way. And so on. All of that is a part of the communication process. – O. R. Mapper Aug 16 '18 at 17:02
128

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.

Elmy
  • 9,784
  • 6
  • 32
  • 43
  • 14
    The woman who ranted at me uses the ticket system daily. – user1261710 Aug 14 '18 at 11:33
  • 5
    @user1261710 Then she really has no reason to complain... All the other answers still apply – Elmy Aug 14 '18 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 Aug 14 '18 at 14:33
  • 1
    I used to work at a company where our system had frequent bugs such that I would hit new ones several times a week, sometimes multiple times a day. I understand the importance of reporting them so I would do so. However, the format for reporting them was so long that it took me about 15 minutes to fill out. I would lose 1-3 hours a week filling out bug reports. YElm is absolutely right that reporting the bug needs to be as easy as possible, otherwise it's just a pain. – Davy M Aug 14 '18 at 22:07
  • 1
    @user1261710 They use the ticket system daily to process the tickets or to file them? – Crowley Aug 15 '18 at 07:00
  • 1
    Our system is pretty good. No bugs. It's visual studio online. There are some fields to fill out but it doesn't take 15 mins. Maybe 5 or less. – user1261710 Aug 15 '18 at 07:52
  • 1
    @user1261710 You don't need to justify your bug reporting system. It's good to hear that your system is not too complicated and your colleagues use it daily, but this may not be the case for other people who stumble upon your question and might find some usefull information in this answer. – Elmy Aug 15 '18 at 07:56
  • 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. – Lightness Races in Orbit Aug 15 '18 at 09: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 Aug 16 '18 at 14:25
  • 2
    @Nicholas: Exactly, so if the OP stops being the path of least resistance then results will improve ;) But yes resolving any underlying root cause would be a more broad solution. – Lightness Races in Orbit Aug 16 '18 at 14:39
  • 1
    @user1261710 Different roles use ticketing systems for different purposes. Business analysts define requirements, project managers generate reports, QA engineers focus on bugs and test cases, etc. Use of a system does not imply mastery or even comfort with every aspect of it. – Eric Aug 17 '18 at 01:10
  • If people know how to use a fb, they also know how to file a bug. Being lazy or thinking you are entitled to go over the procedures is something different. – Rui F Ribeiro Aug 19 '18 at 13:57
110

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]

knallfrosch
  • 6,905
  • 4
  • 19
  • 25
  • 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 Aug 14 '18 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." :-> – computercarguy Aug 14 '18 at 17:18
  • 1
    Spolsky’s own company recognized that asking people to enter bugs into the FogBUGZ software which they sell is so onerous that the developed a system that allows people simply send an email and a bug will be automatically created. – Ben Mz Aug 14 '18 at 17:31
  • Well, if keeping time by having the bug in the proper software is so crucial, someone will have to use that onerous system. If OP starts doing it itself, the problem liekly won't go away. Best to not reward unwanted behaviour like loudly complaining at the devs desk. – knallfrosch Aug 14 '18 at 18:10
  • 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 Aug 14 '18 at 18:15
  • This is what I stayed to do at my last permanent position. I set up Mantis on an in-house server and was going to use it until everyone else did. But I ended up leaving the company first. – Draco18s no longer trusts SE Aug 15 '18 at 15:38
  • 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 Aug 15 '18 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 Aug 15 '18 at 23:51
  • 1
    Joel can give this advise because he's the boss. A single, militant developer imposing his or her own personal preferred process on the organization is not going to end well. – Eric Aug 17 '18 at 01:13
  • Although it's not "bug tracking" per se, we have a ticketing system at ${EMPLOYER} that I tell people to enter a request into, to document that request before I can implement it in any of the applications where I'm an admin. This is purely to cover my backside so no one accuses me of being the Lone Ranger. I have literally had someone ask "why did you do that?" only for me to produce the ticket number where the same person requested the change. Imagine being thrown under the bus without something like that to prove it was the accuser's fault all along. – Monty Harder Aug 20 '18 at 18:14
  • This is optimistic, but I can confidently say this isn't going to work (in the majority of cases). A lot of people like to complain, but don't like to do work. I have worked with people who have brought up issues on "some page", half a dozen times, never gave details, never filed a bug report on it, nothing. Every single time I tell them to report it, and they don't, and they refuse to give details, so I can't even begin to investigate it. – yeerk Dec 08 '23 at 22:03
31

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.

teego1967
  • 22,553
  • 7
  • 57
  • 81
  • 1
    What if you're fine with forcing your colleagues to comply? :P – PoloHoleSet Aug 14 '18 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 Aug 14 '18 at 18:10
  • 2
    Totally joking, from the jaded person who has to do support and fix bugs side of things. – PoloHoleSet Aug 14 '18 at 18:13
  • 6
    Upvoted for the third paragraph. We have such an "alpha" user, and it's wonderful. – David Thornley Aug 14 '18 at 19:29
28

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.

Peter
  • 2,099
  • 12
  • 12
  • 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. – ratchet freak Aug 14 '18 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 Aug 14 '18 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 Aug 15 '18 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 Aug 15 '18 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. – O. R. Mapper Aug 16 '18 at 12:06
  • @O.R.Mapper - I agree that if the developer and colleague talk rationally and combine to enter the bug it can be much easier to fix - but encouraging them to come over and rant whenever they find a bug can severely affect OPs productivity and may not produce useful information if they are "ranting" instead of "discussing" it. Having them enter a bug, then OP going to discuss anything that isn't clear is more standard practice because it saves discussion time on bugs OP already knows about or can instantly understand. – Dragonel Aug 16 '18 at 18:09
  • Yes, and mark the bug reporter/filer as them. – Harper - Reinstate Monica Aug 19 '18 at 22:54
19

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.

Kilisi
  • 222,118
  • 122
  • 486
  • 793
  • 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 Aug 14 '18 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 – Mindwin Remember Monica Aug 14 '18 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. – O. R. Mapper Aug 16 '18 at 12:03
16

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.

PoloHoleSet
  • 10,633
  • 6
  • 27
  • 38
mhoran_psprep
  • 72,299
  • 8
  • 131
  • 233
  • 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 Aug 14 '18 at 11:05
  • while getting paid is important, if the alpha testing isn't producing reports then how will the product get better. which is why participants need to understand the expectations. – mhoran_psprep Aug 14 '18 at 12: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. – David Thornley Aug 14 '18 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. – mhoran_psprep Aug 14 '18 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 Aug 14 '18 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 Aug 15 '18 at 13:12
  • 1
    "Bugs need to be reported so I can put the time into my timesheet."

    "No they don't. "

    OP says it is required, therefore it is required.

     – industry7 Aug 15 '18 at 18:07
  • 1
    @industry7, I think you missed the point. Timesheets are not the reason why bugs need to be reported. – Wildcard Aug 15 '18 at 20:14
  • @Wildcard "Bugs need to be reported so the quality of the product improves." In order to improve the product, the qa can just walk over to the dev's desk and explain the issue in person. You absolutely do NOT have to but bugs into a tracking system to get them fixed. You're basically telling OP to say to OP's boss: "Fixing bugs doesn't improve our product. Reporting bugs in the tracking system improves our product." – industry7 Aug 16 '18 at 13:50
  • 1
    @industry7: I don't understand where you take the assumption from that bugs not written down will be fixed rather than forgotten. – O. R. Mapper Aug 17 '18 at 15:43
  • @o-r-mapper - I'm not sure where your confusion is coming from. To be clear, all jobs have responsibilities, and if you are incapable of remembering what your job responsibilities are, you will probably be fired. – industry7 Aug 17 '18 at 18:36
15

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.

enderland
  • 110,742
  • 49
  • 328
  • 478
11

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.

Twyxz
  • 19,266
  • 14
  • 62
  • 109
11

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.

davidbak
  • 1,123
  • 7
  • 11
  • 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 Aug 15 '18 at 14:05
  • 3
    As I long-time developer I love reporting bugs in a bug reporting system. :D – Lightness Races in Orbit Aug 16 '18 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 Aug 19 '18 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 Aug 20 '18 at 04:55
  • @hjf sounds like your company learnt the important lesson that no system can replace a good human administrator :-) – Aaron F Aug 20 '18 at 10:33
10

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.

andtodd
  • 2,061
  • 4
  • 9
  • 20
  • 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 Aug 14 '18 at 22:59
10

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.

Simon
  • 3,189
  • 1
  • 16
  • 19
  • 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. – David Thornley Aug 14 '18 at 19:26
7

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.

ManagerOfOne
  • 742
  • 4
  • 8
  • 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 Aug 15 '18 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. – Will Crawford Aug 19 '18 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 Dec 08 '23 at 23:00
6

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.

Chris
  • 239
  • 2
  • 3
4

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

cornelb
  • 149
  • 3
3

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.

Zibbobz
  • 10,337
  • 6
  • 38
  • 69
  • 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 Aug 15 '18 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 Aug 15 '18 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 Aug 16 '18 at 17:57
2

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.

Alex R
  • 655
  • 4
  • 7
  • 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 Aug 15 '18 at 06: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 Aug 15 '18 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) – Will Crawford Aug 19 '18 at 23:39
2

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

arp
  • 1,784
  • 11
  • 12
1

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

blankip
  • 22,297
  • 7
  • 56
  • 86
-2

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.

kraligor
  • 449
  • 3
  • 6
  • 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. – O. R. Mapper Aug 16 '18 at 17:06
-3

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

djsmiley2kStaysInside
  • 662
  • 5
  • 14
  • 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 Aug 14 '18 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... – djsmiley2kStaysInside Aug 14 '18 at 11:26
  • This is not how it works. Also do you expect OP to provide his own prizes? Remember he is not the manager – Twyxz Aug 14 '18 at 11:26
  • Ok ok, prizes maybe theoretical and merely compliments. – djsmiley2kStaysInside Aug 14 '18 at 11:29
  • @djsmiley2k the company has 50 employees. I could very well be that the testers are just consultants that happen to explain the workings of the app to customers, or maybe even salesman. (yes this happens!) A dedicated testing team is not always possible, even if your main product is software, in a small company. – Mixxiphoid Aug 14 '18 at 11:32
  • 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 Aug 14 '18 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 Aug 14 '18 at 13:39
  • 4
    Relevant Dilbert: http://dilbert.com/strip/1995-11-13 . – David Hammen Aug 14 '18 at 16:22
  • I worked at a place that, for a time, literally gave £5 to anyone in the company who found a bug in flagship software, as long as they were outside of the dev team (N.B. we had no dedicated QA; go figure why we needed to bribe people to test for us!). Ultimately though we still didn't get many takers and the devs felt pretty miffed. Because why should others get a bonus for this? I'd find bugs daily but I didn't get any extra money for it. Mind you, I suppose I'd also created them, so... – Lightness Races in Orbit Aug 16 '18 at 14:44