-1

I am having a recurring problem where bugs are cropping up once or twice in a build, and are reported by users but I and my team are not able to replicate them.

What techniques do you use to replicate bugs that are hard to replicate?

Thanks

closed as too broad by Mark C. Wallace, Sarov, Todd A. Jacobs Jun 29 '17 at 14:16

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    This is not a project management question, it should be moved to sqa.stackexchange.com or softwareengineering.stackexchange.com – ppasler Jun 29 '17 at 4:41
  • 2
    Didn't know SQA existed to be honest. Thanks for letting me know. – bobo2000 Jun 29 '17 at 8:37
  • 1
    I'm voting to close this question as off-topic because it belongs on SQA – Mark C. Wallace Jun 29 '17 at 10:01
  • This question is written as a list-generating question, so I can't migrate it. While project teams to manage bugs or do QA, as written this is more of an engineering question than a project management question. With some TLC, the question could be rewritten to be on topic here. – Todd A. Jacobs Jun 29 '17 at 14:15
1

It depends on what sort of bugs (and users) you are talking about.

One thing you should really get set up is some sort of automatic logging tool, that will log whenever an exception occurs in your application. Whether it writes it to a logfile (on a machine you can access, not on your user's machine!) or sends emails directly to developers or a manager or whatever doesn't really matter - just make sure that, whenever the user gets an actual error, the development team is notified (preferably with stacktrace) without any involvement on the part of the user.

What I have set up for my team is an automatic email sent to all developers with stacktrace, time the error occurred, the username of the user who got the error, the application name, and (in the case of desktop application errors) a screenshot. Include whatever information you think will be helpful and can easily be logged.

Of course, that won't help you if the 'bug' is not actually an error ("The documentation doesn't make sense", etc). In these cases, if your users are internal (or absurdly helpful external users), then you should set up some sort of template for them to fill out - at the very least containing a description of the bug, what they expected to occur, and what actually occurred.

  • We are using Sentry to pick up exceptions, the type of bugs which are the difficult ones to spot are the glitches that only appear once but never reappear. They are the bugs we have trouble with. – bobo2000 Jun 29 '17 at 8:38
  • @bobo2000 Any bugs that literally 'appear once but never reappear' are bugs that should not even be fixed. At that point, you're trading the effort to fix it for... what, exactly? Bugs that are difficult to reproduce are one thing, but wasting time on bugs that cannot be reproduced is another. – Sarov Jun 30 '17 at 13:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.