{"id":3340,"date":"2015-07-07T09:07:43","date_gmt":"2015-07-07T07:07:43","guid":{"rendered":"https:\/\/usersnap.com\/?p=3340"},"modified":"2025-08-08T17:56:59","modified_gmt":"2025-08-08T15:56:59","slug":"bad-bug-reports-examples","status":"publish","type":"post","link":"https:\/\/usersnap.com\/blog\/bad-bug-reports-examples\/","title":{"rendered":"When bad bug reports happen to good people"},"content":{"rendered":"\n

You\u2019ve done everything right. You\u2019ve instructed your testers and QA agents, you\u2019ve set up an easy-to-use bug tracking tool and a testing suite for your project. And then it happens.<\/p>\n\n\n\n

Bad bug reports happen to the best of us, and, unfortunately, they can happen often. So, we at Usersnap put our heads together to think of the most common bug reports and ways how to avoid these bad bug reports.<\/p>\n\n\n\n\n\n\n\n

5 bug reports gone wrong<\/h2>\n\n\n\n

So here they are. Bug reports gone wrong.\u00a0If you adopt the\u00a0recommended tactics you might even fall in love with your bug tracking team. Promised \ud83d\ude09<\/p>\n\n\n

Try Usersnap for Bug Reporting<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n

1. The bug report which isn\u2019t filed at all<\/h2>\n\n\n\n

As Enzo Pietzsch, Usability Engineer from Jimdo states<\/a>: \u201cThe worst bug report is the one which hasn\u2019t been filed<\/em>\u201d.<\/p>\n\n\n

\n
\"bad<\/a><\/figure>\n<\/div>\n\n\n

Not having a bug tracking tool in place isn\u2019t an excuse. Not having a user-friendly bug tracking tool doesn\u2019t help you either. Make sure that your clients, colleagues or website visitors can file bug reports as easy as possible. No matter how tech savvy they are. Everyone on the project team should be able to report abnormalities.<\/p>\n\n\n\n

Make it clear right at the beginning of a project how you\u2019d wished to receive bugs. Little hint: email isn\u2019t the preferred medium \ud83d\ude09<\/p>\n\n\n\n

2. The bug report which is filed via email<\/h2>\n\n\n\n

Admittedly, we all have been there. It\u2019s super-easy to start your mail client and send your comments and feedback to the developers in charge. And you\u2019re done. Well, at least you think so.<\/p>\n\n\n\n

For developers and people in charge of reproducing and fixing bugs, it can become quite chaotic when dealing with emailed bug reports. Emails are not easy to structure, prioritize. Emails can get lost in the inbox.<\/p>\n\n\n

\n
\"bad<\/figure>\n<\/div>\n\n\n

If you’re not sure how to submit a bug report, ask the project manager or the person in charge for the QA stage of the project. A ton of time can be saved by using the right<\/em> tools<\/a> during testing & QA.<\/p>\n\n\n\n

3. The bug report which contains no specific information<\/h2>\n\n\n\n

Finding a bug on a website or web application isn\u2019t that much of a joy. Especially if those discovered bugs are critical ones to your marketing or business efforts.<\/p>\n\n\n\n

However, you won\u2019t do any good by submitting a bug report<\/a> by simply stating: \u201dIt does not work!\u201d <\/b><\/p>\n\n\n

\n
\"bug<\/figure>\n<\/div>\n\n\n

There are many more questions which needs to be answered<\/a> in order to solve the occurring problem on your website or web app.  What happened? Where did it happen? And many more questions. More more in-depth information, I’d recommend this post on the 4 Ws of bug reporting<\/a>.<\/p>\n\n\n\n

If there\u2019s one golden rule in bug reporting, I\u2019d probably would be the following: be precise as possible<\/em><\/strong>. Describing the problem in the most specific way possible works for everybody.<\/p>\n\n\n\n

Otherwise, your developer\u2019s inbox or bug thread will look like this one:<\/p>\n\n\n

\n
\"bad<\/figure>\n<\/div>\n\n\n

4. The bug report filed on twitter<\/h2>\n\n\n\n

There\u2019s nothing wrong about a\u00a0twitter conversation with your clients and colleagues. However, those twitter conversations can easily\u00a0lead to lengthy chats about issues in your web app or new feature requests.<\/p>\n\n\n

Try Usersnap for Bug Reporting<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n
\n
\"bug<\/figure>\n<\/div>\n\n\n

Always have a place installed where bugs, issues, change requests and new ideas should go into. Twitter isn\u2019t the right place for filing, storing and fixing bug reports. Make sure to establish common ground where you wish to collaborate on bugs and issues.<\/p>\n\n\n\n

5. Too much bug reports, less resources<\/h2>\n\n\n\n

So you have studiously avoided all mentioned bug reports so far? Great job. Here\u2019s a common mistake which happens to the best people. You\u2019ve instructed your QA team, installed a bug tracking workflow and your testers are now motivated to test your app. Great job.<\/p>\n\n\n\n

However don\u2019t forget about the development- and bug fixing<\/em> resources on the other end as well. Try to set up an interactive and flexible bug tracking workflow. Otherwise your development resources will look like this:<\/p>\n\n\n

\n
\"bad<\/figure>\n<\/div>\n\n\n

How to solve the issue of bad bug reports?<\/h2>\n\n\n\n

So here\u2019s the thing. Developers in charge consider other things more helpful for reproducing and fixing bugs than most bug reporters.<\/p>\n\n\n\n

Filing a bug report is quite a time consuming process which means that filing a bug report isn\u2019t on the agenda of most website visitors or team members. So what to do? Especially when working with smaller teams an agile approach to bug tracking is key.<\/p>\n\n\n\n

    \n
  1. Conduct comprehensive alpha and beta tests<\/b> before going to production: Testing your application or website during development not only saves you a ton of time after release, but also prevents you from failing.<\/li>\n\n\n\n
  2. Get every team member on board <\/b>and raise awareness: Tracking bugs means asking questions. If you stumble upon an abnormality\u00a0during the design, prototyping or development phase of your project, simply start asking questions<\/a>. The more questions are answered during the development, the less bugs will make it to\u00a0the production environment.<\/li>\n\n\n\n
  3. Find a common (play) ground: <\/b>Before starting to test your website or app, make sure to find a common tool which is used for tracking bugs. Ideally, you\u2019re using an easy-to-use bug tracking tool, like Usersnap<\/a>, for all your bug tracking activities.<\/li>\n<\/ol>\n\n\n\n

    Further useful resources on the topic of bug tracking:<\/strong><\/p>\n\n\n\n