2

We have been looking at automatically logging all unexpected client errors to our bug tracker. For reference our application is written in Java/GWT/Guice/Hibernate/Jetty and our bug tracker is the hosted version of FogBugz which can create bugs programatically or via an email.

The biggest problem I see with doing this is stack traces that happen in a loop overload the bug tracker by creating thousands of cases. Does anybody have a suggested way to handle automatic bug creation like this?

benstpierre
  • 32,833
  • 51
  • 177
  • 288

3 Answers3

4

If you're using FogBugz bugscout (also see up-to-date docs here) then it has the ability to just increase number of occurences of same problem, instead of creating new case for same exception again and again.

Peter Štibraný
  • 32,463
  • 16
  • 90
  • 116
0

Are you sure that you want to do that?

It obviously depends on your application but even by carefully taking care of the cases that could generate lots of bug reports (because of the loops) this approach could still end up filling the bug tracker.

How about this? Code your app so that every time an exception is thrown, you gather info about the client (IP, login, app version, etc) and send that + the stack trace (or the whole exception object .ToString()) by email to yourself (or the dev team).

Then on you email client, have a filter that sorts that incoming mail and throws it in a nice folder for you to look at later.

Thus you can have tons of emails about maybe one of more issues but then you don't really care because you input the issues yourself in the bugtracker, and easily delete that ton of mail.

That's what I did for my app (which is a client-server desktop app). It plays out well in this case.

Hope that helped!

tzup
  • 3,566
  • 3
  • 26
  • 34
0

JIRA supports automated issues creation using so called services: documentation.

Does anybody have a suggested way to handle automatic bug creation...?

Well, I have. Don't do that.

What are you going to gain from that? Tester's effort? in my experience, whatever effort one can save from that was lost multiple times with overhead transferred to developers who had to analyze and maintain the automatically created tickets anyway. Not to mention overall frustration caused by that.

  • The least counterproductive way I can imagine would be something like establishing a dedicated bugs category or issue tracker instance, such that only testers can see and use it.
    In that "sandbox", auto-created bugs could be assigned to testers who would later pass analyzed and aggregated bug reports to developers.
    And even in that case, I'd recommend to pay close attention to what users (testers) say about the system. If they, say, start complaining about the system, consider trying a manual way of doing things instead.
gnat
  • 6,213
  • 108
  • 53
  • 73