Getting feedback from your users is an incredibly important part of the development and support process.
However, traditional methods of learning about your critical defects are often not sufficient for producing
User-reported bugs can get delivered in many different ways: emails to your support team, posts to your
support forum, angry tweets, issues posted to GitHub, random posts on stack overflow.
All too frequently, users just ignore the defect and move forward as best they can.
However, if your goal is to find viable fixes to real bugs as quickly and efficiently as possible, then
counting on your users to report when they run into bugs comes with some real trade-offs.
#1 User-reported bugs are short on actionable data
Users kind of stink at providing information that makes tracking down crashes easy for you. User-reported
issues often focus on how frustrated they are, and the thoughtful reports can still easily not miss
including data that helps you figure out what went wrong.
The best way to fix a bug is to have it captured locally in a debugger. This provides the data that helps
you identify what went wrong. When was the last time a user provided you with the source code line number
where the crash occurred?
#2 User reports are not an excellent early alert system
As hard as you try, there are going to be bugs that get shipped to your users. It's a reality of
developing software. There's too much complexity in modern development to avoid having unexpected crashes
affect your users.
If you wait for users to report that this is happening, then you've lost the ability to fix the issue
before it becomes a problem for your broader install base.
#3 They don't help you measure frequency
Looking at user-reported bugs isn’t an accurate way to measure how often your application is crashing. All
you can really tell is how frequently your users are reporting your problems. This may be proportional to
how often certain crashes are happening—but then again, who knows?
#4 Reporting is removed from the event
When you rely on users to report their bugs through email or online forums, there are multiple steps
between them and providing their feedback. This makes it less likely that they will actually report the
issue, and it affects the reliability of the reporting because time has passed since it happened.
#5 It's a bad user experience
Manually reported bugs are already such a headache that your users went out of
their way to report the problem. Ideally, you'd be able to save your users from this pain by getting early
warnings before a bug becomes a real issue for your users, allowing you to push a fix before a bug becomes a
real problem for a large part of your users.
What's the fix?
All of these issues create costly inefficiencies and add unnecessary tasks to your support process.
Luckily, they're also totally avoidable.
Automating the process of collecting data around crash defects—also known as crash reporting—fixes all of
the above issues with user-reported crashes.
Crash reporting gives your team data on defects as soon as they start causing crashes for your customers.
BugSplat even points you directly to the exact line of code which caused the crash in the first place.
The huge amount of data automatically collected by crash reporters dramatically shortens the time it takes
to go from identifying a crash to finding the fix. You’ll have a new version released that fixes your issue
before your users can start complaining about crashes and poor performance.
If you’re interested in trying out crash reporting for yourself, join the thousands of developers who use
BugSplat to fix crash defects for over 250+ million of their customers every day.
Stay up to date
Subscribe to our newsletter to get all new posts and updates sent to your inbox.