Issue tracking and Crash Reporting software: what’s the difference?

By Freyja Spaven | Posted Aug 2, 2017 | 6 min. (1248 words)

Issue tracking and crash reporting tools often end up under the same umbrella. And understandably – they both have similar names!

The key difference is where they sit in your development workflow:

Many Crash Reporting tools are built to compliment issue tracking tools. When paired together they form a powerful error resolution workflow.

Here are seven reasons why you’ll want to run both tools together.

1. Significantly reduce time spent replicating issues

Issue trackers (like JIRA, Pivotal Tracker, Assembla, etc.) allow you to distribute error fixes to your development team in the form of tasks or stories. But there’s a limit on the information you can provide in the ticket around a crash if all you have is vague reports from your QA team.

An essential part of keeping a project on time is the estimations function inside your issue tracker. Most teams allocate around 20% of their development time to fixing errors and defects. In our development team, for example, we use JIRA to track and estimate time. We have a good measure on how long bug fixes take because we use Crash Reporting to triage issues before we allocate the ticket. (Below is an example of how Raygun collects and groups errors (which can be dragged and dropped into the different tabs):

For example, you can see at a glance if there an error in the JavaScript caused by a poor deployment on the payment page affecting 200 customers in 1,000.

This error would need immediate attention, and should be labeled “critical.”

Crash Reporting allows you to prioritize based on the number of affected users and the number of occurrences. This removes ambiguity around the importance of errors. An issue tracker doesn’t allow this level of detail. The most important distinction on the level of detail provided is if you have a source control software integrated with your Crash Reporting, (GitHub, GitLab, BitBucket, etc.), you can go straight from the stack trace to the exact line in your source code that caused the error in the first place.

You can’t do this with an issue tracker alone, especially if you aren’t a developer and/or when you don’t have access to the source control. Even if you do have access, without Crash Reporting, you’ll need to remember it and enter it into the issue tracker manually, which can chew through precious project time.

3. More detailed reporting on errors

At the end of the quarter, you may check in and report on the team’s performance. But how did your customers respond to all the great work you did? And how can you translate the great job your team does into a dollar amount for management? While issue trackers report on deliverables, Crash Reporting visualizes data on software quality:

Issue trackers offer reports on deliverables:

Crash Reporting reports on overall software quality:

4. Give your team the power and visibility to resolve their own errors without micromanagement

If an error occurs unexpectedly, you want your best developer on the case quickly.

Both tools allow for better resource management by helping to plan based on task estimates. With issue tracking, if someone didn’t finish a task, or has too many tasks in their sprint, there will be an indicator inside the task.

Issue trackers and Crash Reporting software empower your developers to solve problems quickly. When Crash Reporting is integrated with Slack, errors will Developers can, therefore, fix it them themselves without you having to allocate them.

5. Find out who are your most active team members

Issue trackers can tell you who your most active developers are (who is introducing and resolving errors), but Crash Reporting gives you more detailed context.

For example, a developer may have fixed the most amount of errors issue trackers and Crash Reporting, but these errors may have been minor. Compare that to a developer who may not have resolved as many errors, but has solved a handful of critical errors affecting payment pages or your VIP customers. Issue trackers won’t be able to give that level of detail.

It’s not about keeping tabs on your developers (although it helps to surface productivity problems), but this can help keep your team sufficiently challenged.

What do I mean by that?

Well, small fixes present great learning opportunities for junior developers, where this would frustrate a senior. The level of detail offered by Crash Reporting allows teams to be more strategic about their error fixes and approach errors as a learning opportunity rather than a time for finger-pointing and panic.

6. Integration with Real User Monitoring

With Crash Reporting, each user gets a profile, with a full history of errors and crashes that they have experienced. This is of particular importance because different users and actions can trigger the same error. Issue tracking requires someone to give an example in the ticket details, but there may be other situations and user journeys that trigger the same error that the author of the ticket may miss.

Having all of the session details ensure that the developer fixing the bug, is fixing it for good, not just for that particular use case.

If you are using both Crash Reporting and Real User Monitoring, this data can be cross referenced with any crash report the user experienced. This information is immensely helpful inside an issue tracker as developers get to the cause quicker. (Below is a visual representation of performance from Raygun’s Real User Monitoring tool:)

Using Crash Reporting and Real User Monitoring together will tell you:

John Smith started a session on my application. He then:
Navigated to through these pages
Encountered specific performance issues
Experienced this particular unhandled exception
Left the application at this point

It looks like John had a bad session and experienced several problems. Did this only happen to John, or do these issues affect many users?

Crash Reporting and Real User Monitoring work together to list the actions that led up to a problem, providing the human element behind the data. The session information gives an easy way to understand information without the need for paragraphs of text from the product manager inside your issue tracker.

7. Do my VIPs have a good experience?

Issue trackers form a critical part of budget management for project managers. See how long projects are taking, enter estimates, and pull reports for managers.

Unlike issue tracking software, tags and custom data in Crash Reporting allow you to tag VIP customers. With issue tracking and Crash Reporting working together, directly link the financial value to the error or performance problem. So next time when your website goes down, you can provide a strong argument for the reasons why and the steps your team took to fix it.

So, how different are issue tracking and Crash Reporting?

Very different!

The critical difference is that Crash Reporting groups errors automatically. In an issue tracker, you could be creating a task for every error instance, making it too noisy to be useful.

This is why both tools are valuable to your workflow. For example, here is what an issue resolution workflow looks like with JIRA Software (BitBucket, HipChat, JIRA) and Raygun Crash Reporting:

Therefore, implementing both into your technology stack will give a holistic view of what’s happening in your application.