Incorporating Crash Data Into Your Workflow

Crash reporting can alter the balance between support and development, and swing it in your favor!

Share:

Literally nobody likes crashes....


Sure "literally" is an overused term. But, I think it’s fair to say that “LITERALLY” nobody likes it when software crashes.

Users don’t like it when the software they love using breaks. They’re left wondering what happened and how long will it be until there’s a fix.

Your team doesn’t like fixing crash defects - it takes up free cycles and makes it hard to get started on new projects.

And, most importantly, you don’t like having to spend time chasing down crash defects in your code. You’d probably rather be doing something else.

So there it is—crashes suck.

Still, crashes are an unavoidable part of development. You literally can’t build and support software without crashes. So…if nobody likes them, and they’re bound to happen, shouldn’t you have a bullet proof workflow for minimizing their impact on you, your team, and your users?

Sure you should! Your workflow would automatically track software crashes and provide the following information:

  • Which defects are causing the most crashes?

  • Which versions of your code are affected?

  • What exactly caused the crash?

  • What line of code was responsible for it breaking?

  • What information did your application log that is useful?

  • What automated feedback can you get from your users to help locate the steps leading to the crash?

With that kind of data, you can craft a stellar workflow that will remove critical crash defects and decrease the time it takes for you to find and fix them. This is what the workflow might look like.

1. Prioritize which defects you need to fix.

How often has a scary sounding support email or an especially "squeaky" customer derailed you from your current tasks for hours or days?

Probably too often.

When you know how frequently a crash is occurring across your installed base, it’s much easier to determine what to fix. You no longer have to rely on ‘gut feel’ or how frantic a user sounds.

2. Figure out what’s broken at a glance.

Once you’ve determined a defect is critical to fix, you can use the set of crash reports collected by your automated system to guide you to the solution.

Your crash reporting tool will provide you with data that you would see if you replicated the crash inside a debugger. It will show you a symbolic call stack and point you to the exact line of code that caused the crash. In environments that support it, you'll even get to inspect local variables and function arguments. This drastically cuts down the time it takes to fix the bug.

You could go from “S!%$, what’s broken?” to “Ohhh snap, that’s what’s broken!” in record time.

3. Track crash defects in your bug tracking system.

Your team has lots of stuff to fix. Easily tracking critical crash defects along with the rest of your bugs is critical.

Each new issue you track should include the collected crash data which points directly to the root cause of the defect. Moving between your bug tracking and automated crash collection solutions must be easy!

4. Deploy your fix and monitor its effectiveness.

Once you’ve fixed this critical defect, it will be shipped in your next release.

To determine that the fix was successful, you’d want to track the health of your new release to make sure the crash is no longer occurring.

5. Keep an eye out for potential disasters.

Finally, you'd want an early warning system for when things are going really, really wrong. Learning about spikes in crash volume from an automated system lets you know there’s a critical error before your users figure it out and start peppering you with support calls.

If you can get these alerts sent to you via email, Slack or text, then you’re golden. There’s no way you’re missing the next big bug.

The payoff.

With this kind of workflow in place, it’s easy to see how a team could decrease the time spent on fixing defects and maintaining their deployed code.

It’s also straightforward to see how implementing this workflow could make your software more stable. If you know the handful of crash bugs that are most frequently affecting your users, and you fix them, then your software will crash less often. Waay less often.

This all leads to a more productive team and and happier customers because—remember the theme of theme of this post—NOBODY LIKES CRASHES.

This is, in fact, the exact workflow that BugSplat users employ everyday to make their lives easier and customer experience better.

You'll love having the BugSplat workflow in place. It means you will spend less time fixing your bugs, and your users and other stakeholders will love that your software is more stable.

BugSplat 101

Check out our other guides for getting you up and deployed with BugSplatf

Sign up for BugSplat

30-day trial. No credit card needed.